» 【第97号】属性と定義域

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第97号】属性と定義域

DRI通信97号「属性と定義域」       2004.10.1
10月の声を聞いて、ようやく涼しくなってまいりました。皆さんお元気ですか。
DOA+コンソーシアムの代表ということで、私は、さる9月22日、モデリングフォラム2004において、「DOAとオブジェクト指向の連携」というプレゼンをいたしました。「合計値」といったメタメタデータにロジックを用意すれば、「受注合計金額」とか「月次売上数量」といったメタデータごとにロジックを用意する必要はなくなります。この方式、DOAによって、メタデータとメタメタデータの関係を明らかにし、オブジェクト指向によって、メタメタデータに対するロジックを用意する役割分担が、正解ではないか、と提案いたしました。
また9月28日には、DOA+コンソーシアム第2分科会において、住友電工(株)中村伸祐氏より「DOA+とOOPによるモデル駆動型アプリケーション開発」の発表がありました。あらかじめ標準化して作成したJavaコンポーネントが、リポジトリに蓄えた設計情報を読み込んで即実行する方式で、生産性はCOBOLの約3倍上がり、さらに倍増をねらっているとのことでした。
今月は久しぶりに、情報システムのマネジメント問題を離れ、データモデルの基本問題を考えます。
■ 属性
属性とは、エンティティの性質を記述するためのデータ項目で、たとえば製品、発注について次のように表現します。
 製品:[品#]−(品名、単価、品種*、・・)
 発注:[発注#]−(発注先#*、メーカ#*、品#*、数量、納期、発注日付、・・)
ここに、角括弧にはKEY(識別子)属性を、丸括弧には従属属性を書きます。#は番号と読んでください。*は参照KEYと呼ばれる性質の属性で、「どこかでKEYとして定義されているからこれを参照している」と言うことを表します。俗に言えば、「コード類です、テーブルを参照してください」と言うことです。この属性のことを、英語では、昔はPropertyとも呼んでいましたが、最近はAttributeが一般的のようです。


製品は、社員、顧客と並ぶビジネスに不可欠な3大リソースのひとつです。マスターと呼んでいる会社も多いようです。発注は、受注、出荷などと並ぶイベントの代表です。イベントは、出来事の記録/Factですから、これには誰が、誰に、何を、何時といった属性が、一般には参照KEYとして含まれます。発注の例では、発注先:だれに、メーカ:誰の、品:何を、になりますし、納期、発注日付には*が省略されていますが、何時を表します。したがってこれらの参照KEYはFactを記述するために用いられた用語/Termであり、したがってリソースは用語辞書、広辞苑相当のものといえます。
ここで注意しておきたいことは、属性は意味を持っている、たとえば
 発注先#:誰に発注(to Whom)
 メーカ#:誰の(製品を)発注(Whose)
 品#:何を発注(What)
 数量:どれだけ(How much)
納期:何時までに(by When)
発注日付:何時(When)
のような意味を表しているということです。これはリソースの属性でも同様で、製品については、
 品#:何が(What ID)
 品名:どんな名前(What name)
 単価:いくら(How much)
 品種:どんな分類の(What kind)
といった意味を表しています。
■ 定義域
定義域とはその属性がとる値の形式と範囲を言います。一番大まかに捉えるならば、ある大きさ/長さのコード値、数値、テキストの3つ、ないしこれにピクチャなどを加えた4つ、になります。形式には階層があって、おおまかには
 コード値:数字<英数字<・・<2バイトコード
 数値  :金額<・・<自然数<整数<・・  (ただし浮動小数点数を除く)
 テキスト:1バイト文字<2バイト文字(日本語など)
のようになっていて、これに桁数が絡んでくることになります。
この定義域は、入出力フォーマットを決めたり、入力時に値のチェックに使われます。一般にはチェックのニーズに合わせてこの中の適切なレベルを選べばよいのですが、参照KEYに関しては、入力時の値のチェックに、KEYとの照合が必要になります。たとえば発注における品#としては、そのときすでに登録されている品#−これをわれわれは(活動)KEY定義域と呼んでいます−でなければなりません。したがって
 参照KEY←(活動)KEY定義域
 非参照KEY←定義域
のように、とるべき値のチェックを行うことになります。
(注)活動KEY定義域とは今すでに登録されているKEYの値から作られる定義域を表し、KEY定義域はKEY値としてとりうる定義域を言います。両者をあまり区別しないでKEY定義域という場合があります。値の範囲については、次ぎの順序があります。
 活動KEY定義域<KEY定義域<定義域
■ 管理すべきメタデータ
私はセミナーにおいてよく、上の製品、発注の事例に関し、「この場合皆さんは、いくつデータ項目として登録しますか」と伺います。答えは、8,9,10,11と分かれますが、一番多いのが9または10になります。11の人は属性を、8の人は定義域をデータ項目と考えているわけですが、10の人は用語が同じだから品番は1個と数えているようです。9の人は発注先#とメーカ#は同じと定義域を考えているのですが、さすがに納期と発注日付は同じにしたくないと、自分のフィーリングで回答したものと見えます。このように、
属性と定義域、すなわちデータ項目の意味と形式、をしっかり理解していないと、人により認識するメタデータの数すら合わなくなり、とても高品質のデータの標準化にはいたりません。
データの標準化というと用語の標準化から入る人がいますが、用語はあるコンテキストの中で通じればよいと、適宜省略しますので注意が必要です。たとえば、エンティティの中でその定義域のデータ項目が1個しかないと
 発注品番→品番
 発注数量→数量
 登録品番→品番
のように省略しますので、もっと広いデータベース全体で識別するときには、エンティティIDを補わなければならなくなります。そうすると、エンティティの中に2個以上同じ定義域のものがあるため、親品番、子品番のように、すでに識別ができているものと違った扱いになり、無用の複雑さを招くことになります。
 
家庭では「ひろし」、「たけし」と呼んでいても、学校では、佐藤浩、佐藤武というように、エンティティタイプ内での識別でなく、データベース全体での識別に耐える、データ項目IDでなければならないと考えます。われわれは「生産管理では部品名でなく部品番号で管理する、同様にデータ項目も属性番号を取り、名前は人に優しく適宜省略する」方式を薦めています。
属性か定義域か、はたまた用語か、この差異をはっきり理解しておかないと、RDBの設計まではできても、広域システム統合、EA/情報資源管理、プログラミングレスなどには繋がりません。是非早いうちに高品質のデータの作れる体制・文化を築いていってほしいと思います。