前回までは、トップダウンで切り出したモデルに対して、主キー候補属性やエンティティについて説明してきた。
次に行うのは作成したモデルに対してボトムアプローチをすること。
ボトムアップアプローチは、画面や帳票、データベースから属性を見つけ出す
なぜ、ネーミングが必要なのか?
モデルを見る人や扱う人が複数いることが多いからである。 また、モデラーが一人だったとしても、保守/開発者が複数いれば、なんらかのルールが必要になるネーミング表示の策定
データ標準化を進める上で、最低限なルールを紹介する。 Primer(主要語)、修飾語(Qualifier)、分類区分語(Class)の組み合わせによるネーミング標準を紹介。 データ項目は大きく3つの要素から成り立っているとの考え方に基づき、要素となる単語の用語集を整備し、 それら用語の組み合わせによって硬毛を決める。ドメインとは
ドメインは、データの型やデータの取りうる値、データの範囲の規定でデータ項目の組成が決定される。次に、ドメインを決定するにあたり、「区分」がポイントとなる。例えば、口座種別によれば1:定期預金 2普通預金、3 当座預金などのように定義する。そうすることで、ドメイン上でバリデーション(有効値)を規定することで個別の設定が不要になる。ドメインの分離
ドメインをどのレベルまで定義するかは悩ましいいところである。まず、ドメインを2分割に分ける. 共通ドメインと業務固有ドメインである。共通ドメインは基本コード、氏名、住所など「業務に関連することなく」使えるドメインを指す。一方で、業務ドメインは言葉通り、業務に関連するドメインを指す。例えば、ECであれば 仕入れや物流、購入などといった内容である。 共通ドメインは、組織、、商品に関係なくドメインを扱う リソース系ドメインを指す。一方で、業務固有ドメインは
ドメインと用語集をもとに因数分解
ドメインにドメイン名をつけていく必要がある、そのために「因数分解」をしていく必要がある。 データ標準化でもいかにどんな要素の組み合わせかを知る必要があり、因数分解のように、あるデータ項目を 「因数分解」のように分解する必要がある。 ドメインの定義、つま理因数分解が終われば、次は要素の組み合わせを光量する必要がある。 主要後、修飾語、文理分区語に分解する。 例えば、顧客のメールアドレス、顧客の住所であれば、顧客が就職後にあたる。 メールアドレスと住所については、分類区分語にあたる。ドメインを因数分解し、何を示しているかを明確化
→その上で、主要語、就職語、分類区分語にさらに分解する。
ここでは例を表示しないが、スプレなどで表を作成しエンティティ、データ項目ごとに表でまとめることがポイントである。
ここでの目的はデータ項目の標準化であり、データ項目を正式にドメインに区分させることがポイントである。
なので、そのデータが何のデータであるのかを
主要語や修飾語、区分単語句に分離することがポイントである
ネーミング項目を遵守するツール
いくら、ルールを設定してもモデラーが別々作業すると、同じ名前のデータ項目や同じ意味を持つ項目が定義されてしまう。これを防ぐために、自動検証&生成ツールを作成すると便利。 Ex エクセルなどデータ項目を構成する要素
ドメインを割り付けたり、構成単語に分解するのは、データ項目を真に理解するためである。理解したデータ項目について、知り得た情報をデータ項目の属性として定義する。- 名称
属性名:モデル上の論理名称(日本語)
カラム名: DBMS実装上の名前
モデルとしての名前である日本語名をそのまま用いることも可能
- 意味定義
- ドメイン
- データタイプ(文字型、数値型、日付型)
- 桁数(長さ)
- デフォルト
- ルール制約: ドメインで定義する有効値