物理データモデル (PDM) の概要
by Scott
W. Ambler, Copyright 2003
データモデリングとは、データ指向の構造を調査する作業のことです。他のモデリング成果物同様にデータモデルも、大雑把な概念モデルから物理データモデル(physical data model: PDM)まで、さまざまな目的に使うことができます。物理データのモデリングは、概念的には設計クラスのモデリングと同じで、データベースの内部スキーマを設計して、データテーブルとそのデータの列、テーブル間の関係を記述することが目的です。
図1は大学システムのPDMの一部です。これがすべてでないことは、この図に表示されていないテーブルの外部キーがSeminarテーブルに含まれていることから分かりますし、率直に言ってしまえば、コースや教授といった多くのドメインの概念がモデリングされていないことからも明白です。ほとんどの箱がテーブルを表していますが、唯一の例外はUniversityDBで、ここにはデータベース内で実装されたストアドプロシージャが書かれています。図には<<Physical Data Model>>というステレオタイプが付けられているので、クラスの箱がテーブルを表していることが分かりますが、図のステレオタイプがなければ、テーブルごとに<<Table>>というステレオタイプを付ける必要があったかもしれません。テーブル間の関係は標準のUML表記法でモデリングされています。この図にはありませんが、テーブル間の集約や継承関係をモデリングしてもよいでしょう。関係はキーを使って実装します(これについては後で詳しく述べます)。
図1. 大学システムのPDMの一部
物理データモデリングを行うには、以下の作業を反復的に行ないます。
-
テーブルを識別する：テーブルはデータベース上でクラスに対応するものです。データは物理テーブル上に格納されます。図1を見れば分かるように、大学システムでは、学生データをStudentテーブルに、コースデータをCourseテーブルに格納します。図1ではUMLベースの表記法を使っています(これは誰でも意見が言える公に定義されたプロファイルです)。すでにクラスモデルがあるなら、まずクラスをデータテーブルに1対1でマッピングするとよいでしょう。このアプローチは、データベーススキーマを一から定義できるという素晴らしい「新規開発の」環境ではとても役に立ちます。ただしそのような環境は実際にはめったにないので、既存のデータベーススキーマという制約があってそのスキーマに自分のクラスをマッピングしなければならない、という状況を覚悟しておく必要があります。そのような状況では、大規模なデータモデリングをしなければならない可能性は低く、既存のデータソースとどう折り合いをつけるかを学べばよいだけですが、既存のモデルを読んで理解できなければなりません。場合によっては、レガシーデータ分析をして既存スキーマをモデリングしてから、作業にかからなけれがならない可能性もあります。
-
テーブルを正規化する：データの正規化とは、データモデル内のデータの属性を整理して、テーブルの凝集性を高くし、テーブル間の結合度を低くするというプロセスです。その基本的な目的は、データが1箇所だけに格納されるようにすることです。1つのデータ属性が複数の場所に格納されていると、オブジェクトを関係データベースに格納することは非常に困難になるため、これはアプリケーション開発者にとっては重要な考慮事項です。図1のテーブルは第三正規形(3NF)になっています。
-
列を識別する：列はデータベースで属性に対応するもので、各テーブルには1つ以上の列が存在します。たとえば、StudentテーブルにはFirstNameやStudentNumberといった属性があります。基本型でも他のオブジェクトでもかまわないクラスの属性とは違って、列はchar(文字列)やint(整数)やfloat(浮動小数)などの基本型でなけれぱなりません。
-
ストアドプロシージャを識別する：概念的に、ストアドプロシージャはデータベースによって実装されたグローバルメソッドのようなものです。図1では、averageMark()やstudentsEnrolled()といったストアドプロシージャは、UniversityDBクラスの操作としてモデリングされています。これらのストアドプロシージャでは、データベース中に格納されたデータを扱うコードを実装します。この例では、学生の平均点を計算したり、あるゼミに登録している学生の数を数えたりします。ストアドプロシージャの中には明らかに1つのテーブル中に含まれるデータだけを使った処理をするものもありますが、それをテーブルの一部として(クラスの一部であるメソッドと同じように)モデリングすることはありません。ストアドプロシージャは1つのテーブルではなくデータベース全体に属するものなので、データベースの名前を持つクラスの一部としてモデリングします。
-
命名規則を適用する：組織にはデータモデリングに適用できる標準やガイドラインが必要であり、ない場合には用意するよう働きかけるべきです。ここでもやはり、AMの「モデリング標準を適用しよう」のプラクティスに従ってください。
-
関係を識別する：クラス間に関係があるように、テーブル間にも関係があります。UMLクラス図の関係を識別する方法と同様な方法を用いればよいでしょう。
-
データモデルパターンを適用する：人によっては、データモデリング時に一般的なデータモデルパターンを適用します。このテーマに関しては、David Hay(1996)の著書『Data Model Patterns』が参考文献としてもっとも優れています。概念的にデータモデルパターンに一番近いのは、一般的な領域の問題に対する解決策を記述していることから、アナリシスパターンだといえます。Hayの著書は、分析レベルのモデリングを行う人にとって非常に優れた参考図書となります。彼のパターンは広範なビジネス領域のビジネス構造をモデリングしているため、データアプローチではなくオブジェクトアプローチを取っている場合でさえも非常に役立ちます。
-
キーを割り当てる：キーとは、テーブル中の1つの行を一意に識別する、1つ以上のデータ属性です。2つ以上の属性からなるキーを複合キーと呼びます。エンティティ型のキーとしては主キーが好んで使われますが、代替キー(二次キーとも呼ばれます)を使ってテーブル内の行にアクセスすることもできます。物理データベース内で、キーは、リレーショナルテーブル内で行を一意に識別する値を持った、1つ以上の列から構成されます。主キーは<<PK>>、外部キーは<<FK>>というステレオタイプを付けて表します。キーについて詳しくはこちらを参照してください。
同じような表記法で書かれてはいますが、図1のPDMとそのもととなったUMLクラス図との間には興味深い違いがあります。
-
キー：一般的に、クラスモデルでは実装の便宜で必要な属性はモデリングしませんが、データモデリングではキー(枠組みに相当するデータ)はモデリングするのが普通です。
-
可視性：列はすべてpublicなので、可視性はモデリングしません。ただし、ほとんどのデータベースではアクセス制御権をサポートしているため、UMLの制約やUMLのノートを使ったり、あるいはビジネスルールとして、可視性をモデリングすることができます。同様にストアドプロシージャもpublicなのでモデリングしません。
-
多対多の関連が存在しない：リレーショナルデータベースはオブジェクトと違って、もともと多対多の関連をサポートすることができません。そのため、関連テーブルを追加して実現する必要があります。図1で関連テーブルに一番近いのはWaitListで、これはクラス図にあるon waiting listという名前の多対多の関連を実現するために加えられたものです。純粋な関連テーブルは、関連を保持するための2つのテーブルの主キーの列から構成されます。この場合、StudentのStudentNumberとSeminarのSeminarOIDです。WaitListの中で、これらの列に<<PK>>と<<FK>>の両方のステレオタイプが付いていることに注意してください。これらはWaitListの主キーを構成しているのと同時に、別の2つのテーブルの外部キーにもなっているためです。WaitListは、Addedというキーではない列を含んでいるため、厳密には関連テーブルではありません(この列は、空きができたときに、順番待ち名簿の先頭の人が登録する機会を与えられるようにするためのものです)。WaitListが純粋な関連テーブルであれば、私は<<associative table>>というステレオタイプを付けているでしょう。
アジャイルさを保つ
私は物理データモデルを作成する場合、たいていはCASEツールを使います。私がデータモデリングツールに必要だと思う機能には、データベーススキーマを作成するためのデータ定義言語(DDL)を生成する機能と、既存のデータベーススキーマからデータモデルをリバースエンジニアリングする機能の2つがあります。現在市場に出回っているほとんどすべてのデータモデリングツールはこれらの機能をサポートしています。
注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。本ではより詳しく説明しています。
アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。 
Ronin
International, Inc. continues to help numerous
organizations to learn about and hopefully adopt agile
techniques and philosophies. We offer both
consulting and
training
offerings. In addition we
host several sites - Agile
Modeling, Agile
Database Techniques, UML
Modeling Style Guidelines, Enterprise
Unified Process (EUP) - that you may find of value. You
might find several of my books to be of interest,
including
The Object Primer, Agile
Modeling, The
Elements of UML Style, and Agile
Database Techniques. For more information please
contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).
visits since November 17 2003.
|
