データモデリング ネーミング標準とドメイン データモデリング ネーミング標準とドメイン

なぜ、ネーミング標準が必要か 大きなシステムは複数人でモデリング それぞれが勝手な名前付けを行うと整合性がとれない。 異音同義語（シノニム synonym） 同じ実体を別の言葉で表現 同音異義語（ホノニム homonym） 異なる実体を同じ言葉で表現 こっちのほうが厄介

DBMe書店での同音異義語 異なる実体であることがある。 贈り物の場合

住所の他に電話番号や郵便番号も

Quiz: なぜ同音異義の属性があっては困るのか？ オブジェクト指向の世界では、オブジェクトの名前が違えば、インスタンス変数の名前は同じものがあってもよいはず オブジェクト指向DBでなく、関係DBだから 複数の開発者で必ず一意に属性を識別するため 開発者とユーザとの意識を統一するため Join が ある から

[補助] なぜ，joinがあると困る？ Joinでは異なる表の中の属性が１つの表にに結合される 名前 住所 電話番号 顧客 お届け先 名前 住所 電話番号 名前 住所 電話番号 送り主とお届け先の対応 名前 住所 電話番号 これでは，どれがプレゼントの送り先かわからない

名前の付け方がまちまちでも困る 実際にあった話 高齢者見守りのユビキタス・システム開発時 状況キャッシュの省略形がJC 抽象状態（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