データモデリングとは 何か

第 １ 章 11

データモデリングと言った場合，データベース設計のために構造図を描くことと

理解されている方が多いのではないかと思います。間違いではありませんが，筆者

は，データモデリングをデータベース設計の手法だけでなく，企業システムの要求

を捕捉するための手法と捉えています。その原点は，企業システムを捉えるのに，

まずそこで取り扱われているデータに着目して，それらの関係を明らかにすること

から始めようという，DOA(データ中心設計)と呼ばれる考え方です。DOA の目指す

ところは，企業内のデータを重複なく配置しようということですから，そのための

データベース設計にさかのぼ

遡 ってみる必要があると考えます。

一方，データモデリングの成果が現れるデータベースを格納する仕組みとしての

DBMS の歴史を振り返ります。販売，購買，会計といったビジネスアプリケーショ

ンの領域では，もともと台帳で種々の管理が行われていました。これを，システム

ではファイルやデータベースとして置き換えたわけですから，台帳を形成している

データに着目して分析を始めるというのは，当たり前の話なのです。

温故知新と言われますが，日進月歩の IT業界でも，特に著者が対象としているビ

ジネスアプリケーションの領域では，ここ 30年本質は変わっていないということを

実感しています。本質さえ見失わなければ，IT 技術がどんなに進化しようとついて

行けると考えています。そのためにここで，先輩たちが残してくれた実績を振り返っ

てみましょう。本質が見えてくるかもしれません。

本章では，ERモデリングや UMLモデリングの技術基盤となっている DB技術や構

造化設計，オブジェクト指向技術の歴史を紐解きながら，モデリングとは何かをあ

らためて考えてみたいと思います。以下の観点から考察します。

• DBMSの種類を歴史的に振り返ります。

• データベース設計を起点として，データモデルとは何かを説き明かします。

• データモデルを含めて，モデルとは何かを再認識しましょう。

• データモデリングの原典である構造化分析とは何か。

• UML利用の根底にあるオブジェクト指向分析・設計とは何か。

13

1.1 データベースと DBMS

本書の主題であるデータモデリングの目的は，システム構築の一工程としては

データベース(以下 DB)を生成することである場合が多数を占めます。DB とい

えばリレーショナル(RDB)という時代が 20 年も続いています。IT 技術の革新が

これだけ激しい時代において，既に 20 年以上もの間主流として君臨している要

素技術があるとは驚くべきことです。もちろん，RDBMS のエンジンとしては各

ベンダー間でしのぎを削っていますので，進化してきているのですが，基本的な

原則，応用技術という点では，その登場以来変わっていないといえるでしょう。

そんな，DBMS の歴史から入っていきたいと思います。 1.1.1 歴史

現在，企業システムで最も多く用いられている DBMS(データベース管理シス

テム)といったら，RDB(リレーショナル DB)でしょう。1970 年代末に登場して

から 30 年近くが過ぎ，なお盛んに使われています。当初はアクセスコストが非

常に高く，日常業務，特にトランザクション処理系業務には使えないと言われて

いましたが，DBMS エンジンの改良とハードウェアの劇的な革新による処理系の

性能向上により，ごく当たり前に使われるようになりました。ここでは，RDB登場以降の歴史をおさらいしておきましょう。 1970 年に，E.F.Codd 博士が「Relational Model of Data for Large Shared Data Banks」でリレーショナル理論を世に出したのが始まりと言われます。そ

れ以前は，商用のDBMSとしては，IBMの IMSに代表される階層型やCODASYLのネットワーク型をベースにした商用 DBMS が主でした。それらの DBMS は，

あらかじめ親子関係の構造やアクセス経路が定まっており，データを自由に取り

出し加工することができませんでした。そこに全く新たに，行と列という単純な

表概念と集合概念による関係モデル理論を考案したのです。このコッド博士の理

論を基に商用 DB として，1979 年に Oracle，1981 年に IBM の SystemR(後の

SQL/DS，DB2)，そして Ingres(現在 Computer Associates 社)などの DBMSを各メーカーが競って出荷してきたのです。

14

1.3 モデリングツールの系譜

RDBMS は集合演算により検索を行うため，CPU 負荷が大きく，当時のハー

ドウェアでは日常業務で使用するには，十分でありませんでした。しかし，

RDBMS の登場は，DBMS という器だけでなく，SQL というデータ操作(アクセ

ス)言語(正確には，DDL というデータ定義言語，DCL というデータ制御言語を

含みます)を伴っていたため，非常に大きなインパクトを与えることになりまし

た。当初は CPU 能力や DBMS エンジンのアルゴリズムの未成熟により所定のレ

スポンスが得られませんでしたが，販売実績データや顧客データなどを多方面か

ら検索する，情報系と呼ばれる用途に絞って積極的に使用する企業が増えていき

ました。これも，SQL という言語で，欲しいデータを簡単に取り出せるため，日々

変わるエンドユーザの要求に応えることができるという理由が大きかったので

す。 90 年代に入って，C/S(クライアント/サーバー)システムの台頭と共に，

RDBMS は爆発的に普及していきました。何しろ，C/S システムの中核となった

のが RDBMS だったからです。RDBMS は，複数ユーザからのデータの蓄積・検

索を排他制御し，整合性の取れたデータを保つという本来機能はもちろん，スト

アードプロシジャーやトリガーといったデータアクセス周辺のデータ加工処理

やビジネスロジックなど，従来プログラム言語が担っていた機能も実装できるよ

うになったのです。ですから C/S システムは，RDBMS と，データ操作結果を画

面に表示し入力データを受け取るGUIツールがあれば構築できたのです。OracleやSQL ServerとVisual BasicやPower Builderといったツールの組み合わせが

もてはやされていたことは，皆さんもご記憶のことと思います。 オープンシステムの賑やかさと平行して，プログラミングや開発方法論として

オブジェクト指向の足音が徐々に近づいてきました。オブジェクト指向にはもと

もと，外部データを扱うという概念はなく，乱暴に言ってしまえば，すべてをメ

モリ内に展開して処理しようという考え方ですから，RDB とは相性が良くない

わけです。そこで，オブジェクトをそのまま格納しておけるデータベースとして

OODB(オブジェクト指向データベース)が登場しました。例えば，ObjectStore，Versant，O2 などです。 これらはポスト RDB として近い将来 RDB にとって代わるだろうといわれて

いたのですが，現実には，RDB がそのまま使い続けられています。その理由は

いろいろあると思いますが，一番の理由は，OODB は閉じられた世界だというこ

15

とではないでしょうか。RDB ならば，セキュリティを考えなければ，構築され

た DB を誰もが SQL で簡単にアクセスできます。また，企業システムでは，いっ

たん DB として構築されると当初のシステム構築時にはなかったような要求が

次々と出てきます。これに柔軟に対応できるのも RDB の良さではないでしょう

か。逆に OODB では，新たな要件が出てきた場合に，その情報を取り出してく

るためのメソッド(≒プログラム)を新たに書く必要があるのです。 私たちの対象とするビジネスアプリケーションは，顧客や商品に関するデータ

や受発注の取引データを扱うものであり，データに対して無限の要求が発生して

いるといってもよいでしょう。それらの要求に柔軟に対応できることが，RDBの大きな利点と考えます(図 1.1)。

メーカー依存の汎用機

情報系システムエンドユーザコンピューティング要求

OODB

RDB

専用DBMS（階層型，ネットワーク型）

多面的なアクセス要求

オープンなSQL

オブジェクト指向

OODBは，アプリケーション専用DBであり，専用

アプリケーション以外からのアクセスが難しい。

RDBは蓄積されたデータを後から活用するのが

容易（ビジネスアプリケーションの性格に向く）。

図 1.1 ポスト RDB

RDB がそのまま使い続けられているといいつつも，製品そのものは多くの機

能が追加されてきています。データ構造に関わるところでは，オブジェクトの格

納機能(この結果，オブジェクトリレーショナル DB などと呼ばれることもある)

と XML エクステンダー機能が大きなところでしょう。

16

1.3 モデリングツールの系譜

1.1.2 種類

1.1.1 項の歴史で触れた DBMS のいくつかについて，その特徴と簡単な仕組み

を見てみましょう。今日，なぜ RDB が使い続けられているのか，その一端が理

解できるのではないでしょうか。 (1) 階層型

IBM 社の IMS が有名であり，メインフレーム全盛期に金融，製造業など多く

の企業で採用されてきました。特徴は次の通りです。

• データ構造をセグメント単位で分割しキーの階層構造で定義する。 • 各セグメントは，キーエリア＋データエリアから構成される。 • データエリアに格納される個別の属性定義は行わない。

つまり，データエリアをまとめて受け取って，そのレコードをプログラム上で

構造定義しておくことになります。そのため，データエリアは，あらかじめ将来

を見越して若干余分に確保しておくことが多いです。データエリア内に収まる範

囲での属性定義の変更は，データベースへの変更を伴いません。ただし，当該セ

グメントをアクセスしているプログラムはすべて影響を受けることになります。

• データの取り出し・格納方法としては，キーの順番に取り出す方法(Get Next)，特定のレコードをキー値を指定して取り出す方法(Get Unique)など

があります。 • データアクセスパターンが限られるが，高速であるため，データ構造が安定

した基幹業務に適す。例えば，銀行支店ごとの顧客の口座管理などです。 このようにデータ構造の変化が少なく，アクセスパターンが固定的である場合

には，高速アクセス(更新も含めて)を実現できる OLTP 向けの DBMS といえま

しょう(図 1.2)。

17

ルートセグメント

子セグメント

孫セグメント

子セグメント

キーエリア＋データエリア支店

顧客

口座

ex)ルートセグメント

子セグメント

孫セグメント

子セグメント

キーエリア＋データエリア支店

顧客

口座

ex)

支店

顧客

口座

ex)

図 1.2 階層型

(2) リレーショナル 行(ロウ)と列(カラム)の表(テーブル)でデータ構造を表現したもので，Excelを代表とするスプレッドシートの寄せ集めと考えてもよいでしょう。スプレッド

シート 1 枚 1 枚が，「社員」とか「組織」といったテーブルに相当することにな

ります。ただし決定的な違いは，リレーショナルモデルでは，個々のカラムに対

して型(データタイプ＋長さ)を定義することと，テーブルとテーブルが何らかの

関係付けで結ばれるということです。 ここで，階層構造 DB との決定的な違いが出現していることにお気づきでしょ

うか。階層構造では，データエリアすべてを合わせた長さ分だけのエリアを 1 つ

確保していただけですが，リレーショナルでは，1 つ 1 つのカラムを定義してい

るのです。これ以外に SQL というアクセス言語の登場が，その後のリレーショ

ナルの普及に大きな役割を果たすことになるわけですが，データ構造的には，す

べての属性定義をデータベースに対して行うというところが階層型ではなかっ

た点で，データベースやデータ管理に携わる人間にとって，ものすごく革新的な

ことだったわけです。 しかし，このすべての属性を定義するということが，20 年以上経た今日でも正

しく行われていないという事実をしばしば目にします。階層型のときには，デー

タアクセスするプログラムによって受け取りエリアを個別に定義しており，DB上何が格納されているかはプログラムだけが知っていたのですが，RDB の時代

18

1.3 モデリングツールの系譜

になってもその状況はなかなか変わらなかったということでしょう。図 1.3 は，

受注明細としてDB上定義されているエリアをプログラムAとプログラムBで，

異なった用途に使用しているという例です。RDB を使っているといいつつも，

こんな使い方がなされていたりするのです。

受注番号 受注年月日 取引先コード 受注金額

受注明細テーブル受注番号 商品コード 受注数量 受注単価

プログラムA プログラムB

受注番号 商品コード 受注数量 受注単価 受注番号 商品コード 受注数量 出精値引

受注テーブル

受注明細エリア 受注明細エリア

RDB

受注番号 受注年月日 取引先コード 受注金額

受注明細テーブル受注番号 商品コード 受注数量 受注単価

プログラムA プログラムB

受注番号 商品コード 受注数量 受注単価 受注番号 商品コード 受注数量 出精値引

受注テーブル

受注明細エリア 受注明細エリア

RDB

図 1.3 RDB の誤った使い方

では，リレーショナル型について少しまとめておきましょう。

• RDB では，すべての属性を定義し，テーブル間の関連を主キー(キー属性)

で捉える。 • RDB へ実装するテーブル定義体(DDL)を作成する前に，業務の世界から

テーブル候補(エンティティ)を切り出してモデル化することが必要だ。 • 業務の世界の関係を捉え(＝意味を把握する)てリレーション付けする。

(3) XML XML は，もともと文書管理の SGML のサブセットとして登場してきました。

インスタンス(データ値)とインスタンスが何を表しているのかを示すメタ定義

(タグと呼ぶ)を，渾然一体で定義しています。さらに，メタ部分だけを定義した

DTD や XML スキーマ定義などもあります。XML スキーマ設計では，Primary Key や Foreign Key 定義などもあり，RDB 定義と類似しています。

19

<?

xml v

ersi

on="

1.0"

?><注文注文番号

="10

0001

">　　

<注文日

>200

0/10

/12<

/注文日

><配送先国名

="日本

"><氏名

>鈴木花子

</氏名

><番地

>１－２－３

</番地

><市区町村

>文京区後楽

</市区町村

><都道府県

>東京都

</都道府県

><郵便番号

>112

-000

4</郵便番号

></配送先

><請求先国名

="日本

"><氏名

>山田太郎

</氏名

><番地

>４－５－６

</番地

><市区町村

>千代田区一ツ橋

</市区町村

><都道府県

>東京都

</都道府県

><郵便番号

>101

-000

3</郵便番号

></請求先

><コメント

>誕生日プレゼント

</コメント

><商品

><商品商品番号

="87

2-A

A">

<商品名

>Law

nmow

er</商品名

><数量

>1</数量

><価格

>148

.95<

/価格

><コメント

>Con

firm

this

is e

lect

ric</コメント

></商品

><商品商品番号

="92

6-A

A">

<商品名

>Bab

y M

onito

r</商品名

><数量

>1</数量

><価格

>39.

98</価格

><配送日

>200

0/10

/30<

/配送日

></商品

></商品

></注文

>

<xsd

:sche

ma

xmln

s:xs

d="h

ttp://

ww

w.w

3.or

g/19

99/X

MLS

chem

a">

<xsd

:ann

otat

ion>

<xsd

:doc

umen

tatio

n>Pu

rcha

se o

rder

sche

ma

for E

xam

ple.

com

.C

opyr

ight

200

0 Ex

ampl

e.co

m. A

ll rig

hts r

eser

ved.

</xs

d:do

cum

enta

tion>

</xs

d:an

nota

tion>

<xsd

:ele

men

tnam

e="注文

" typ

e="注文型

"/>

<xsd

:ele

men

tnam

e="コメント

" typ

e="x

sd:st

ring"

/>

<xsd

:com

plex

Type

nam

e="注文型

"><x

sd:e

lem

entn

ame=

“配送先

" typ

e="住所

"/>

<xsd

:ele

men

tnam

e="請求先

" typ

e="住所

"/>

<xsd

:ele

men

tref

="コメント

" m

inO

ccur

s="0

"/>

<xsd

:ele

men

tnam

e="商品

" ty

pe="

Item

s"/>

<xsd

:attr

ibut

ena

me=

"注文日

" typ

e="x

sd:d

ate"

/></

xsd:

com

plex

Type

>

<xsd

:com

plex

Type

nam

e="住所

"><x

sd:e

lem

entn

ame=

"氏名

" ty

pe="

xsd:

strin

g"/>

<xsd

:ele

men

tnam

e="番地

" typ

e="x

sd:s

tring

"/>

<xsd

:ele

men

tnam

e="市区町村

" ty

pe="

xsd:

strin

g"/>

<xsd

:ele

men

tnam

e="都道府県

" ty

pe="

xsd:

strin

g"/>

<xsd

:ele

men

tnam

e="郵便番号

" t

ype=

"xsd

:dec

imal

"/>

<xsd

:attr

ibut

ena

me=

"国名

" typ

e="x

sd:N

MTO

KEN

"us

e="f

ixed

" val

ue="日本

"/>

</xs

d:co

mpl

exTy

pe>

<xsd

:com

plex

Type

nam

e="注文商品

"><x

sd:e

lem

entn

ame=

"ite

m"

min

Occ

urs=

"0"

max

Occ

urs=

"unb

ound

ed">

<xsd

:com

plex

Type

><x

sd:e

lem

entn

ame=

"商品名

" typ

e="x

sd:s

tring

"/>

<xsd

:ele

men

tnam

e="数量

"><x

sd:si

mpl

eTyp

eba

se="

xsd:

posi

tiveI

nteg

er">

<xsd

:max

Excl

usiv

eva

lue=

"100

"/>

</xs

d:si

mpl

eTyp

e></

xsd:

elem

ent>

・・・・

　　・・・・

XMLインスタンス

XMLスキーマ定義

RDBスキーマ定義と類似

注文書

注文番号

注文日

氏名

郵便番号

都道府県

番地

商品番号

商品名

数量

価格

配送日

配送先

請求先

市区町村

商品

<?xm

l ver

sion

="1.

0"?>

<注文注文番号

="10

0001

">　　

<注文日

>200

0/10

/12<

/注文日

><配送先国名

="日本

"><氏名

>鈴木花子

</氏名

><番地

>１－２－３

</番地

><市区町村

>文京区後楽

</市区町村

><都道府県

>東京都

</都道府県

><郵便番号

>112

-000

4</郵便番号

></配送先

><請求先国名

="日本

"><氏名

>山田太郎

</氏名

><番地

>４－５－６

</番地

><市区町村

>千代田区一ツ橋

</市区町村

><都道府県

>東京都

</都道府県

><郵便番号

>101

-000

3</郵便番号

></請求先

><コメント

>誕生日プレゼント

</コメント

><商品

><商品商品番号

="87

2-A

A">

<商品名

>Law

nmow

er</商品名

><数量

>1</数量

><価格

>148

.95<

/価格

><コメント

>Con

firm

this

is e

lect

ric</コメント

></商品

><商品商品番号

="92

6-A

A">

<商品名

>Bab

y M

onito

r</商品名

><数量

>1</数量

><価格

>39.

98</価格

><配送日

>200

0/10

/30<

/配送日

></商品

></商品

></注文

>

<xsd

:sche

ma

xmln

s:xs

d="h

ttp://

ww

w.w

3.or

g/19

99/X

MLS

chem

a">

<xsd

:ann

otat

ion>

<xsd

:doc

umen

tatio

n>Pu

rcha

se o

rder

sche

ma

for E

xam

ple.

com

.C

opyr

ight

200

0 Ex

ampl

e.co

m. A

ll rig

hts r

eser

ved.

</xs

d:do

cum

enta

tion>

</xs

d:an

nota

tion>

<xsd

:ele

men

tnam

e="注文

" typ

e="注文型

"/>

<xsd

:ele

men

tnam

e="コメント

" typ

e="x

sd:st

ring"

/>

<xsd

:com

plex

Type

nam

e="注文型

"><x

sd:e

lem

entn

ame=

“配送先

" typ

e="住所

"/>

<xsd

:ele

men

tnam

e="請求先

" typ

e="住所

"/>

<xsd

:ele

men

tref

="コメント

" m

inO

ccur

s="0

"/>

<xsd

:ele

men

tnam

e="商品

" ty

pe="

Item

s"/>

<xsd

:attr

ibut

ena

me=

"注文日

" typ

e="x

sd:d

ate"

/></

xsd:

com

plex

Type

>

<xsd

:com

plex

Type

nam

e="住所

"><x

sd:e

lem

entn

ame=

"氏名

" ty

pe="

xsd:

strin

g"/>

<xsd

:ele

men

tnam

e="番地

" typ

e="x

sd:s

tring

"/>

<xsd

:ele

men

tnam

e="市区町村

" ty

pe="

xsd:

strin

g"/>

<xsd

:ele

men

tnam

e="都道府県

" ty

pe="

xsd:

strin

g"/>

<xsd

:ele

men

tnam

e="郵便番号

" t

ype=

"xsd

:dec

imal

"/>

<xsd

:attr

ibut

ena

me=

"国名

" typ

e="x

sd:N

MTO

KEN

"us

e="f

ixed

" val

ue="日本

"/>

</xs

d:co

mpl

exTy

pe>

<xsd

:com

plex

Type

nam

e="注文商品

"><x

sd:e

lem

entn

ame=

"ite

m"

min

Occ

urs=

"0"

max

Occ

urs=

"unb

ound

ed">

<xsd

:com

plex

Type

><x

sd:e

lem

entn

ame=

"商品名

" typ

e="x

sd:s

tring

"/>

<xsd

:ele

men

tnam

e="数量

"><x

sd:si

mpl

eTyp

eba

se="

xsd:

posi

tiveI

nteg

er">

<xsd

:max

Excl

usiv

eva

lue=

"100

"/>

</xs

d:si

mpl

eTyp

e></

xsd:

elem

ent>

・・・・

　　・・・・

XMLインスタンス

XMLスキーマ定義

RDBスキーマ定義と類似

注文書

注文番号

注文日

氏名

郵便番号

都道府県

番地

商品番号

商品名

数量

価格

配送日

配送先

請求先

市区町村

商品

注文書

注文番号

注文日

氏名

郵便番号

都道府県

番地

商品番号

商品名

数量

価格

配送日

配送先

請求先

市区町村

商品

図1.4 XML図

20

1.3 モデリングツールの系譜

XML は，構造的には階層型 DB と類似しており，XML スキーマは RDB のス

キーマ定義と類似していますので，この 2 つの DB に原型を見ることができます

(図 1.4)。 多くの RDBMS では，文書データの格納用途に，RDB 上のテーブルの 1 カラ

ムとして XML データを格納し，取り出す機能が追加されてきています。また，

XML データを RDB テーブルとは別に取り扱う，すなわち日常の業務アプリケー

ションで使用する構造化データは RDB に，ドキュメント，メール，ブログなど

といった非構造化データは XML で管理しようというハイブリッド型の DBMSも登場してきました。 XML の利点は，データ構造の追加・変更が容易だということです。RDB の

SQL に相当する Xquery や SQL/XML が用意されています。RDB とうまく住み

分けて，今後利用が促進されていくのではないかと考えています。 (4) オブジェクト オブジェクト DB については歴史でも述べたように，純粋なオブジェクト指向

DB は少なくなってきているようです。RDBMS 製品の中には，メソッドや継承

関係を定義できる機能を追加できるようになってきているものもあります。また，

RDB の強力な武器である SQL アクセスが可能な半オブジェクト DB(CHACHEなど)も出てきています。オブジェクト指向で設計した結果の永続化機能として

素直に実装できるとともに，別なシステムや直接ユーザが SQL でアクセスでき

るようにという要請からなのでしょうか。

21