PhD Thesis Review, No.7

学位論文紹介概念モデリングに基づく O/R マッピ
ング手法に関する研究༢⣧࡞ᑐᛂ㛵ಀ」㞧࡞ᑐᛂ㛵ಀ㎿㏿࡞㛤Ⓨྥࡅ

」㞧࡞࢔ࣉࣜࢣ࣮ࢩࣙࣥࣟࢪࢵࢡ࡟ᑐᛂ

eer ĺ rs, spc

 eer :EER ࣔࢹࣝ㛤Ⓨ⪅ࡀグ㏙㸦ධຊ㸧

eer(概念モデル)A Study on an O/R Mapping Method
based on Conceptual Modelingov1

ovn + eer ĺ cpcn

ovn : ObjectView
ov2 ov3, ov4, …
(eer に追加)
rs, spc, cpcn ࢆ⏕ᡂ

rs
 rs

 cpcn: Ọ⥆໬ࢡࣛࢫ
cpc3, cpc4, … (複雑な対応関係)(単純な対応関係) DBPowder ࡀ⏕ᡂ㸦ฟຊ㸧 RDB ࢔ࢡࢭࢫࢥ࣮ࢻが，生成された永続化クラス（spc, cpcn）:㛵ಀࢫ࣮࣐࢟

 spc :Ọ⥆໬ࢡࣛࢫ

村上 直 ♥

spc

cpc1 cpc2と関係スキーマ（rs）の対応をとるよう，生成される

Tadashi MURAKAMI

図1

DBPowder フレームワークによる ORM の概要を構成して，複雑な永続化クラスを生成する手法といえる．
本研究では，複数の ORM フレームワークを用いて四点の比較

1. はじめに（イ）開発で必要とされる評価を実施した．
（ア）ORM の記述力，記述量，（ウ）単純な対応関係のみで構成される ORM に対してオブジェクト関係マッピング（ORM）フレームワークは，デー

複雑な対応関係を追加する際に，必要とされる編集回数や単語数，

タベースの利用が不可欠なアプリケーション（DB アプリケーショ（エ）OO7 ベンチマークによる性能評価．比較評価の結果，本研ン）の開発において，永続化対象となるメモリ上のデータをオブ究で示した提案の妥当性が示された．

ジェクト指向言語で扱うための（a）永続化クラス，これを関係

本稿の構成は以下の通りである．2 節で DBPowder を提案し，3 節で本研究の評価と応用事例を示し，4 節でまとめを述べる．

データベース（RDB）上で永続化するための（b）関係スキーマ，
および，永続化クラスから RDB へクエリし応答を受けとる（c）

RDB アクセスコードの三点について，効率的な設計や開発に貢2. DBPowder フレームワーク：概念モデリングに基づく O/R マッピング手法

献する．ORM フレームワークは，永続化クラスとこれを扱う関係テーブルの対応関係に着目することで，二つのグループに大別できる．
（1）一対一を基本とした単純な対応関係（以下，単純な対DBPowder フレームワークによる ORM の概要を図 1 に示す．

（2）単純応関係）を簡易に実現できるフレームワーク [6, 5, 7] ，開発者は初め，EER モデル (eer) [9] のみを記述する．DBPowder

ではない対応関係（以下，複雑な対応関係）を実現できるフレー

は eer を用いて関係スキーマ (rs)，永続化クラス (spc)，およムワーク [2, 1]．

び RDB アクセスコードを生成する．これにより，単純な対応

DB アプリケーションは，小規模なプロトタイプの構築と機能拡張を繰り返す開発方式がとられることが多い．このとき（1）のフ関係による ORM が成立する．開発が進み複雑な対応関係をもつ ORM が必要になった場合には，開発者は eer に加えてレームワークでは，開発が進み永続化クラスと関係テーブルの対

ObjectView(ovn ) を記述する，DBPowder は eer と ovn を用いて複雑な対応関係をもつ永続化クラス (cpcn ) を生成する．
本研究で扱うオブジェクトモデルは，ODMG3.0 [4] のサブセットを基本とし，Java を参考にした拡張を含む．図 2-1 の (a)–(g)

応関係が複雑になった場合の対応が難しい．一方で（2）のフレームワークでは，単純な対応関係を簡易に記述できない上に，機能拡張の繰り返しに伴ってこの対応関係を度々修正する必要が生じ（1）と（2）のサポー
る．このように ORM フレームワークでは，に例を示す．本研究で扱う関係モデルは一般的に定義されるモデトの両立と，単純な対応関係から複雑な対応関係に移行する開発

ルを想定しており，図 2-1 の (h)–(k) に例を示す．本研究で扱うの効率的なサポートが望ましいが，既存の ORM フレームワーク

EER モデル [9] は，ER モデルを拡張してオブジェクトモデルを

ではこれは容易ではない．

扱えるようにしたものであり，図 2-1 の (p)–(s) に例を示す．

このような問題の克服のために，本研究では ORM フレーム

2.1 節で EER モデルを用いた単純な対応関係による ORM に

ワーク DBPowder を提案する．DBPowder では，単純な対応関ついて述べ，2.2 節で ObjectView を加えた複雑な対応関係に係の簡易な実現が要求される開発初期には EER モデル [9] によ

よる ORM を述べ，2.3 節で eer と ovn を記述するための言語
DBPowder-mdl を示す．

る概念モデリングにより開発を進め，複雑な対応関係の実現が要求される際には EER モデル上の実体の走査経路と利用方法を指2.1

定した有向グラフ ObjectView を追加する．提案手法の特徴は，

EER モデルと ObjectView の連携により，（1）と（2）のサポー

迅速な開発が求められる開発フェーズでは，開発者は eer のみ

トを両立し，単純な対応関係から複雑な対応関係に移行する開発を記述する．DBPowder は eer を解釈し，単純な対応関係をもつを効率的にサポートできる点にある．また本手法は，概念モデル

rs と spc を生成する．この手順を ORM 手順 1 – 4 に示す．

上の実体や関連を追加的あるいは修正的に指定して ObjectView♥

EER モデルによる単純な対応関係を簡易に実現できる ORM 手法

ORM 手順 1 DBPowder は，eer 上の主キーが省略された実体に，代理キーを追加する．

正会員 高エネルギー加速器研究機構 計算科学センター（現職），筑波大学大学院システム情報工学研究科コンピュータサイ
エンス専攻修了（北川研究室） tadashi.murakami@kek.jp

ORM 手順 2 DBPowder は，Teorey らの手法 [9] に基づき，
eer から rs を生成する．

17-1

2014 年 5 月

日本データベース学会

PhD Thesis Review, No.7

学位論文紹介
(e)

.

(f)

.

(g)

.

(h)

.

ᅗ2-1: ༢⣧࡞ᑐᛂ㛵ಀ(q)registeruser_name(p) user

n
1 (r)

n

1

(i)

.

(j)

.

eer

(k)

.

(l)

.

(m)

.

(n)

.

(o)

.

(p) E: ᐇయ
reg_datehost(q) A: ᒓᛶ
ip_addr (r) R: 㛵㐃
C: 㐃⤖ᗘ
guest_user
host_name (s) ỗ໬㝵ᒙaffiliation

(sr)
(s)

adm_useradm_rolers, spc 䛾⏕ᡂᅗ2-3: DBPowder-mdl EERᐉゝ㒊

ᅗ2-4: DBPowder-mdl ObjectView ᐉゝ㒊

1:[user] E: ᐇయᐉゝ
2: user_name text A: ᒓᛶᐉゝ
3: [<1:n> register] L: 㛵㐃ᐇయ4:
reg_date Dateᐉゝ
5:[<n:1> host]6:
ip_addr text
7:
host_name text
8: [<inherit-sr> adm_user]
9:
adm_role text ỗ໬㝵ᒙ10: [<inherit-sr> guest_user]
11:
affiliation text

1:[user]
PN : ጞⅬᐉゝ㸦୰ᚰᐇయ࡟ᑐᛂ㸧
2: [RegHost@register] 1:[host]3:{host}
2: [RegUser@register]
4: {adm_user}
3:{user}
5: {guest_user}N : ⠇Ⅼᐉゝ㸦ᐇయ࡟ᑐᛂ㸧GN : ࢢ࣮ࣝࣉ໬⠇Ⅼᐉゝ class-assigned-name@EER-assigned-name

(a)

(a)
(c)
(d)

.

(a)

.

(b)

.

(a)

..

(b)

.

(b)

.

(c)

.

(c)

.

(d)

.

(d)

.

(e)

.

(c)

.

.

(d)

.

(e)

.

(f)

.

.

(f)

.

(g)

.

(e)

(e)

.

(f)

.

(g)

.

(h)

.

(f)

.

(g)

.

(h)

.

(i)

.

(g)

.

(h)

(i)

.

(j)

(h) ࢸ࣮ࣈࣝ (i) ᒓᛶ(j) ୺࣮࢟(k) እ㒊࣮࢟nregister1

1 host(中心実体: host)ov2

register
n

user

host

adm_user guest_user
cpcn 䛾⏕ᡂ
eer : EERモデル
ovn : (複) ObjectView
rs : (単) 関係スキーマ
spc : (単) 永続化クラス
cpcn : (複) 永続化クラス(単) 単純な対応関係をもつ(複) 複雑な対応関係をもつ

..

.
.

ov1
user

DBPowder 開発者
が生成
が記述

rs

緑領域：グループ化(中心実体: user)

spc

Register(c)register_id n Hostn
1 user_id
1 host_id
user_id (b) (d) host_id
ip_addruser_namereg_date
host_nameregister[](c)userregister[]host(getters / setters)(getters / setters)(getters/
setters)(e)(a) ࢡࣛࢫ
AdmUser(f) GuestUser(b) ᒓᛶ(c) 㛵㐃
adm_role
affiliation(d) ከ㔜ᗘ(getters / setters)(getters / setters)(e) ⥅ᢎ
(f) Ꮚࢡࣛࢫ
user(h)register(g) ぶࢡࣛࢫ
user_id (j)register_id
hostuser_name (k) user_id(FK)host_iduser_type(i) n host_id(FK)adm_role 1 reg_date
n ip_addr
1 host_nameaffiliation

User(a)(g)(b)

ᅗ2-2: 」㞧࡞ᑐᛂ㛵ಀ ʊ RegHost や RegUser

 RDB 䜰䜽䝉䝇䝁䞊䝗が，spc と rs，cpcn と rs の対応をとるよう，生成される

cpc1

RegHostRegUserregister_id
Usern user_id
1 host_id
user_iduser_namereg_date
regHost[]user
ip_addr(getters / setters)
host_nameregister_id
user_id
host_id
reg_datehostuser_name(getters / setters)(getters / setters)

AdmUser

GuestUser

adm_role

affiliation(getters / setters)(getters / setters)

cpc2
n

Host
1 host_id
ip_addrhost_nameregUser[](getters / setters)

図 2 単純な対応関係（左側 図 2-1），複雑な対応関係（右側 図 2-2），DBPowder-mdl EER 宣言部（中央 図 2-3），

DBPowder-mdl ObjectView 宣言部（右側 図 2-4） [8]ObjectView は，以下に示す ov 記述 1, 2, 3 から構成される有向グラフ G によって定義される．開発者が記述する ObjectViewの内容に従って，DBPowder は cpcn を生成する．

ORM 手順 3 DBPowder は，ORM 手順 2 と類似の方法により，eer から spc を生成する．

ov 記述 1 アプリケーションロジックが必要とする実体と関連

ORM 手順 4 DBPowder は，単一テーブル継承（SR），クラステーブル継承（CR），具象テーブル継承（CCR）として知られる方法 [5] により，eer の汎化階層を rs で扱う．

の，走査経路の指定による，有向グラフ G

はじめに ov 記述 1 で，開発者は対象のアプリケーションロジッ
クが扱う実体 E と関連 R を指定する．このうち，アプリケーショ

単純な対応関係における ORM 手順 1 – 4 の実施例を 図 2-1

ンロジックが中心に扱う実体を中心実体とよぶ．開発者は，実体に示す．開発者は eer のみを記述する（図上部）．この eer にE を節点，関連 R を枝，中心実体を始点と見立てて，必要な要素を指定した有向グラフ G を記述する．G 内のそれぞれの枝は終点側にもとの R に対応した連結度をもち，G 内のそれぞれの節点はもとの実体 E 内の属性 A を引き継ぐ．このようにして，ObjectView は EER モデルにおける連結度や属性を引き継ぐ．

基づき，DBPowder は rs と spc を生成する（図下部と中部）．

ORM 手順 1 – 4 に基づいて生成された rs と spc の対応関係を，
DBPowder では単純な対応関係と定義づけている．

2.2 ObjectView による複雑な対応関係を実現できる
ORM 手法ov 記述 2 G を単純化するための，G の節点のグループ化指定

複 雑 な 対 応 関 係 を 実 現 す る た め に ，DBPowder で は ObjectView を導入する．ObjectView は，EER モデルに対するov 記述 2 では，始点から辿って連結度が 1 の枝を用いて節点をグループ化することで，ov 記述 1 で指定した ObjectView の構

有向グラフベースのオブジェクト記述形式である．アプリケーショ
ンロジックが必要とする実体と関連について，走査経路と利用方

造を単純化する．

法を指定することで，開発者は複雑な対応関係もつクラス cpcn

ov 記述 3 G の部品化（コンポジション）と多態性（ポリモーを簡潔に記述できる．ObjectView がサポートする rs と cpcn の複雑な対応関係は，以下に示す三種類である．
（a）あるテーブルをフィズム）を実現する，構造化リテラルとインタフェースの指定基準にして多対 1 や 1 対 1 で結合される複数のテーブルを，一つov 記述 3 では，ov 記述 2 でグループ化した ObjectView に対の永続化クラスに対応づける対応関係，（b）テーブルの属性の一部

して，構造化リテラルとインタフェースを用いて部品化と多態性を，対応する永続化クラス内で部品化し，別の永続化クラスとしを実現する．

て対応づける対応関係，（c）複数のテーブルに分散する各々の属性

ORM 手順 5 DBPowder は，ov 記述 1, 2, 3 に示す ObjectView の記述に従い，cpcn を生成する．

の集合を，一種類のインタフェースとして対応づける対応関係．

2

7-2

2014 年 5 月

日本データベース学会

PhD Thesis Review, No.7

学位論文紹介(1-a),(1-b) ༢⣧࡞ᑐᛂ㛵ಀRedmine (1-a)

353
1 365
1 DBPowder
RoR
505 1.43 650 1.78
1,124 3.18 3,051 8.36 Hibernate(EER only)
0

400

800

1200

1600

2000

2400

2800

3200

Magento (1-b)

2,193
1 2,429
1 DBPowder
RoR
4,183 1.91 6,110 2.52
6,078 2.77 16,360 6.74 Hibernate(EER only)
0

2000

4000

6000

8000

10000

12000

14000

16000

(2-a) 」㞧࡞ᑐᛂ㛵ಀ
233 0.71
3261
329 1.01

DBPowderCaveatEmptor (2-a)

257 0.7(EER only)
367
1 DBPowder
812 2.21 Hibernateྜィ ẚ⋡ ྜィ ẚ⋡(EER only, EER and ObjectView)

0
グ㏙㔞㸦༢ㄒᩘ㸧࡟ࡼࡿẚ㍑

syntax ࢆ syntax ࢆ㝖ࡃྵࡴͤẚ⋡ࡣ㸪DBPowder=1࡜ࡍࡿ

100

200

attributeentity, class, tablelinked-entity

300

400

relationship(inv) relationship500(non-CoC)(non-CoC) syntax(inv) syntax
syntax

600

700

800

ͤᏛ఩ㄽᩥ࡛ᑐ㇟࡜ࡋࡓ࢔ࣉࣜࢣ࣮ࢩࣙࣥ
ࡣ㸪Redmine, Magento, CaveatEmptor
ࡢ࡯࠿㸪KEKapp (3.3⠇)㸪OO7࣋ࣥࢳ
࣐࣮ࢡ࡛㸪ྜィ5✀㢮

図 3 開発に要する負担の評価：単語数を用いた記述量の比較（一部抜粋）

1
OO7ベンチマーク
KEKapp: user が中心実体
KEKapp: host が中心実体開発で要した編集回数
（回）
10
100
DBPowderHibernate

1

編集した単語数
10
100

（個）
1000
DBPowderHibernate (増減数)
Hibernate (操作合計)

図 4 開発に要する負担の評価：複雑な対応関係に移行する開発で要した，編集の回数および編集した単語数

3. 評価と応用事例

複雑な対応関係における ORM 手順 5 の実施例を図 2-2 に示

3.1 記述力および開発に要する負担の評価

す．この例の前提として，図 2-1 で開発者が eer を記述済であり，

DBPowder の単純な対応関係や複雑な対応関係への適性を評価

eer に基づき rs と spc を生成済である．図 2-2 では開発者は，
ObjectView ov1 , ov2 を記述する（図上部）．この ov1 , ov2 に基づ
き DBPowder は永続化クラス cpc1 , cpc2 を生成する（図下部）．
ov1 は管理者 user を中心としたアプリケーションロジックを扱っており，ov 記述 1 に示すグラフ構造を記述したのち，ov 記述
2 により節点 register と host をグループ化している．この ov1に基づき DBPowder は永続化クラス cpc1 を生成する，ここでクラス RegHost に対応する rs 上のテーブルは register と hostの二つであり，複雑な対応関係が成立している．ov2 や cpc2 については，ホスト host を中心として，ov1 や cpc1 と類似の関係がするため，記述力の評価，記述量の比較による開発に要する負担の評価（図 3），および複雑な対応関係に移行する開発で要した編
集の回数および編集した単語数の比較（図 4）を行った．比較対象
は DBPowder, Hibernate, Ruby on Rails (RoR) とした．
記述力の評価では，Hibernate がサポートする永続化クラスと関係スキーマの対応関係について，DBPowder-mdl が以下の三つを除いてサポートできることを確認した．1) 関連や継承関係をもたない複数のクラスを一つのテーブルに対応づける，2) SQL 文を永続化クラスや属性に対応づける，3) コレクションを構成するクラスから一属性を選んで配列にして，コレクションを保持する成立している．

クラスの属性として対応づける．

2.3 記述言語 DBPowder-mdl

ORM 実施のための開発に要する負担について，単語数を記述量

DBPowder は記述言語 DBPowder-mdl をもつ．図 2-3, 2-4 に例を示す．DBPowder-mdl の記述形式には EER 宣言部（図 2-3）と ObjectView 宣言部（図 2-4）の二種類がある．
EER 宣言部の基本要素は実体 E ，属性 A，関連実体 L である．
DBPowder-mdl の記述形式は，関連実体 L を導入した上で基本要素を階層構造で記述することにより，EER モデルの記述の際にと見なして比較した結果の一部抜粋を図 3 に示す．学位論文では，5 種類のアプリケーションについて単純な対応関係や複雑な対応関係の複数のパターンを対象とした．各々のアプリケーション上でORM を実現するために必要なスクリプトを DBPowder，RoR，Hibernate で記述し，記述に要した単語数を比較した．XML の
タグ名や属性名のような文法に属する内容は syntax として数え同じ名称を指し示す回数を減らしており，簡潔な記述を可能としることとし，グラフ上では右部に配置した．

ている．なお実体のデータ表現が階層構造では不足する箇所では，比較した結果，DBPowder では必要な記述量を大幅に削減でき

E や L の同一要素を複数回記述することで，グラフ構造を記述でることから，単純な対応関係や複雑な対応関係を簡易に実現でききる．また汎化階層もサポートする．

ることを示せた．RoR ではテーブル名などの命名規則への制約に

ObjectView 宣言部では，中心実体に対応する始点 P N ，節点
N ，およびグループ化される節点 GN を用いて，ObjectView のより開発に要する負担を軽減するが，DBPowder は概念モデルの効率的な記述により開発に要する負担を軽減する．このアプロー

有向グラフを記述する．

チの違いが，RoR と DBPowder の削減効果の差異の要因と考え3

7-3

2014 年 5 月

日本データベース学会

PhD Thesis Review, No.7

学位論文紹介られる．なお Hibernate では，syntax で膨大な記述量を要した．

較と，複雑な対応関係に移行する開発で要した編集の回数および二種類のアプリケーションについて，単純な対応関係から複雑編集した単語数の比較を実施した．その結果，永続化クラスと関な対応関係に移行する場合を想定し，DBPowder と Hibernate

係テーブル間の，単純な対応関係の簡易な実現と複雑な対応関係について開発に要する負担を比較したものを 図 4 に示す．2 種類の実現についてサポートを両立できることと単純な対応関係からとも，DBPowder では移行対象の実体や関連を ObjectView で複雑な対応関係に移行する開発の効率的なサポートが可能である

指し示して記述するのみだが，Hibernate では移行対象のクラス

ことを示せた．また OO7 ベンチマークを用いた性能評価を実施

定義の全体をコピー＆ペーストしたのちに，複数回の編集が発生

し，DBPowder の性能が Hibernate に比べて多くの場合で処理した．結果として DBPowder では開発に要する負担を大幅に軽時間が短くなることを示せた．これらの結果から本研究の妥当性減できており，単純な対応関係から複雑な対応関係に移行する開を示すことができた．

発を効率的にサポートできることが示された．

今後の課題としては，データ更新処理の効率化，大規模データへ

3.2 DBPowder ORM システムと性能評価の対応，リバースエンジニアリング，EER モデルと ObjectView

本 研 究 で は ，2 節 で 示 し た 提 案 手 法 を 実 現 す る シ ス テ ム ，DBPowder ORM システムを提案した．このプロトタイプシ
ステムを構築し，OO7 ベンチマーク [3] を用いた性能評価を実施した．性能評価では，Hibernate で実装された OO7 のオープ
ンソースプログラムと，これを DBPowder に移植したプログラの連携方式の深化が挙げられる．

【文献】[1] A. Adya, J. A. Blakeley, S. Melnik, and S. Muralidhar.
Anatomy of the ADO.NET entity framework. In Proceedings of the ACM SIGMOD International Conference on
Management of Data, Beijing, China, June 12-14, 2007,
pages 877–888. ACM, 2007.
[2] C. Bauer and G. King. Java Persistence with Hibernate.
Manning Publications Co., Greenwich, CT, USA, 2006.
[3] M. J. Carey, D. J. DeWitt, and J. F. Naughton. The
OO7 benchmark. In Proceedings of the 1993 ACM SIGMOD International Conference on Management of Data,
SIGMOD ’93, pages 12–21, New York, NY, USA, 1993.
ACM.
[4] R. G. G. Cattell and D. K. Barry. The Object Data Standard: ODMG 3.0. Morgan Kaufmann, 2000.
[5] M. Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley, Boston, MA, USA, November
2002.
[6] D. Heinemeier and et al. Ruby on Rails. http://www.
rubyonrails.org/. (accessed in Dec. 2013).
[7] C. Kleissner. Enterprise objects framework, a second generation object-relational enabler. In Proceedings of the
1995 ACM SIGMOD International Conference on Management of Data, San Jose, California, May 22-25, 1995,
pages 455–459. ACM Press, 1995.
[8] T. Murakami, T. Amagasa, and H. Kitagawa. DBPowder: A flexible object-relational mapping framework
based on a conceptual model. pages 589–598, 2013.
[9] T. J. Teorey, D. Yang, and J. P. Fry. A logical design methodology for relational databases using the extended entity-relationship model. ACM Computing Surveys, 18(2):197–222, 1986.
[10] 村上 直. DBPowder-mdl: EoD と記述力を兼備した O/R
マッピング言語. 情報処理学会論文誌データベース (TOD),
3(3):46–67, Sep. 2010.

ムで，処理時間の比較を実施した．その結果，多くの場合について，DBPowder のほうが処理時間が短く，またほぼ全てについて，

DBPowder の性能が著しく劣ることはないことを示せた．

3.3 応用事例

DBPowder の初期プロトタイプシステムと，これを用いたウェ

ブアプリケーション（KEKapp）を 2006 年に構築し，以来改良を重ねている．KEKapp は，2006 年より高エネルギー加速器研
究機構でのセキュリティ管理業務で利用されている [10]．さらに，

KEKapp を 2011 年に連携組織 J-PARC に展開した．利用者数
は 2013 年 12 月現在，およそ 140 名である．
KEKapp では追加開発を幾度も行い利用者に提供しており，セキュリティ管理や，部署ごと年度ごとに実施するセキュリティ点検
における，業務上の要望に応えている．ここで，図 3，図 4 などの評価を実施しており，その結果として DBPowder の効果が高い
ことが示された．

4. まとめ
本論文では，概念モデリングに基づく O/R マッピング（ORM）
手法に関する研究として，DBPowder フレームワークを提案した．本研究の貢献は大きく三点を挙げられる．一点目の貢献は，永続化クラスと関係テーブル間の，単純な対応関係の簡易な実現と複雑な対応関係の実現についてサポートを両立できる，実用的な ORM 手法を示したことである．この利点は，EER モデルとObjectView を併用により連携することで，対象のデータモデル
を柔軟に記述できたことで得られた．この方式は同時に，二点目の貢献である，単純な対応関係から複雑な対応関係に移行する開発の効率的なサポートをもたらした．三点目の貢献は，DBPowder

村上 直 Tadashi MURAKAMIのプロトタイプシステムを構築し，実運用環境に適用することでその有用性を示したことである．

1999 年京都大学工学部情報学科卒，2001 年東京大学大学院理学系研究科情報科学専攻修了．SE 職を経て現在，高エネルギー加速器研究機構 (KEK) 計算科学センター助教．2014 年筑波大学大学

提案手法 DBPowder の評価として，記述力の評価と開発に要する負担の評価を実施した．記述力の評価では，DBPowder-mdl の言語定義を，Hibernate の文書型定義（DTD）や Ruby on Rails

院システム情報工学研究科博士後期課程修了．博士（工学）．デーの機能と比較することにより，DBPowder のサポート範囲を確認

タ工学の研究に従事．日本データベース学会，情報処理学会，電した．開発に要する負担の評価では，単語数を用いた記述量の比

子情報通信学会，ACM 各会員．

47-4

2014 年 5 月

日本データベース学会