Document

データモデリング
ネーミング標準とドメイン
なぜ、ネーミング標準が必要か
• 大きなシステムは複数人でモデリング
• それぞれが勝手な名前付けを行うと整合性
がとれない。
• 異音同義語（シノニム synonym）
– 同じ実体を別の言葉で表現
• 同音異義語（ホノニム homonym）
– 異なる実体を同じ言葉で表現
– こっちのほうが厄介
DBMe書店での同音異義語
異なる実体であることがある。
贈り物の場合
住所の他に電話番号や郵便番号も
Quiz: なぜ同音異義の属性があって
は困るのか？
•
Join
が
ある
から
オブジェクト指向の世界では、オブジェク
トの名前が違えば、インスタンス変数の
名前は同じものがあってもよいはず
① オブジェクト指向DBでなく、関係DBだか
ら
② 複数の開発者で必ず一意に属性を識別
するため
③ 開発者とユーザとの意識を統一するため
[補助] なぜ，joinがあると困る？
• Joinでは異なる表の中の属性が１つの表にに結合
される
顧客
名前
お届け先
住所
電話番号
名前
住所
電話番号
送り主とお届け先の対応
名前
住所電話番号名前
住所
電話番号
これでは，どれがプレゼントの送り先かわからない
名前の付け方がまちまちでも困る
• 実際にあった話
• 高齢者見守りのユビキタス・システム開発時
– 抽象状態（Abstract Condition）
– エリアの管理者(Area Concierge)
ともに省略形が AC，名前は同じだが実体は異なる
• 状況キャッシュの省略形がJC
– 状況は英語で situation だから SC のはず
– ちょっと，英語のセンスが疑われる！
ネーミング標準の策定
• 名前の付け方をプロジェクトで統一する
• 紹介するのは３つを組合わせる古典的方法
– 主要語(Prime)：定義したい対象
– 修飾語(Qualifier)：主要語を補足
– 分類区分(Class)：ドメイン
• 用語集（辞書）をプロジェクトで作成
• ドメインは、すべてのプロジェクトに共通のも
のを作っておく
• 欠点は、安易な用語の組合せに陥りやすい
– ホノニムはなくなってもシノニムはなくならない
Quiz: なぜ，シノニムはなくならない
• 同じものに多くの違う名前を付けてしまうの
は？
① ネーミング標準は標準であって，これを守らなけれ
ば処罰されるというほど厳しいものではないから
○ ② ネーミング標準，つまり，ルールが決まっているの
で，命名の責任をルールのせいにして，意味を考
えずに名前を付けてしまうから
③ ネーミング標準は，プロジェクトごとに決めるので，
常に正しいルールになっているとは限らないから
④ 元来，人間は自分だけの名前を付けたがるから
論理名ネーミングルール
• 主要語、修飾語、分類区分語の組み合わせ
でデータ項目名を作る
• 日本語では(修飾語)＋主要語＋分類区分語
• 単語は必ず、プロジェクトの用語集に登録さ
れているものを使う。
– ない場合は登録する
• 各単語の英語を用意しておき、物理データ項
目はこの英語で作る。
論理名ネーミングルールに
少しは融通を利かせるために
• 主要語は修飾語として使ってもよい
• 複数の主要語と修飾語の組み合わせで、新
たな修飾語を作ってもよい
• 修飾語は、用途ごとに分類しておくと便利
– 種別修飾語
– 場所修飾語
– 状況修飾語
など
ドメイン
• データの型や取りうる値・範囲の規定
• C言語などの型よりも抽象度の高いデータ型
– 1月は1日から31日まで
– 預金は、普通、当座、総合しかない
– Excelのセルの書式機能に似ているが，ドメインは自分で
決めるもの
• データモデリングでは強力な武器になる
– 分類区分（ドメイン）をデータ項目名につけると、データの
素性がひと目でわかる
– ドメインを決めることであいまい性がなくなり、分析が進む
[補助]データの素性がわかると…
• 属性名を見ただけで，その属性の値が分かれば，
分析が進む
• 「商品価格」という属性名からは
– マイナスの値はありえない．
– 小数点の値もおかしい
• エンティティ「ショッピング・カート」で
– 属性「顧客ID」と言うのを見ると，エンティティ「ショッピン
グ・カート」はエンティティ「顧客」を参照していることが分
かる
– 属性「顧客ID」が「ショッピング・カート」の主キーの一部な
ら，「ショッピング・カート」は「顧客」に依存していることも
判明する．
Excelのセルの書式設定機能
ドメインの種別
• コード（主キーに使用されるのがほとんど）
– よくある対象を表現する上で、桁数の異なるいくつかの
コードを用意する
– システムごとでコードの型がバラバラにならない
• 区分
– とりうる値の範囲が決まっているもの
– C言語でいうenumeration機能
• 名称
– 分類法がたくさんあり、オブジェクト指向の単一継承では
表せない。
• 漢字とかなの名称、個人名と法人名、などなど
• 住所
– 都道府県名、市町村名、地名と番地、建物などに分ける
分析が進むにつれドメインも詳細化
• たとえば住所の場合
• 初期のモデルでは
– 顧客住所
• 分析と設計が進むにつれ
– 顧客住所_都道府県名、顧客住所_市町村名、顧
客住所_地名
ドメインと用語集をもとにネーミング
① ドメインはすでに定義されているものとする
② データ項目名を構成するための用語集を作ってお
く
③ データ項目に割り当てるドメイン（データの素性）を
見抜く
④ データ項目名を以下の３つの用語に分割する
– 主要語
– 修飾語
– 分類区分（実はこれはドメインだから先に決まっている）
•
この分割のためのルールを決めることがネーミン
グ標準（教科書は因数分解に類似といっている）
DBMe書店の例では
• エンティティ「顧客」でネーミング標準に従った
データ項目名の名前付けをすると
• 「顧客」内のデータ項目名には、顧客を修飾
語につける
• 区分が名前のものには、最後に「○○名」と
する
• 「届け先」「店頭渡し先」でも同様
表6-1

Download Report