Document Actions
データベースの進化的設計
原文(Evolutionaly Database Design)
ここ何年かで私たちはアプリケーションの開発に即してデータベースの設計を進化させることを可能にする技法を編み出した。このことはアジャイルメソッドにとって非常に重要である。この技法は継続的インテグレーション及び自動化されたリファクタリングをデータベースの開発に適用し、かつDBAとアプリケーション開発者が密接に協力することによって成り立つ。この技法は開発中のシステムや既に開発されたシステムに対しても機能する。
近年、私たちはソフトウェア開発の新しい潮流を目の当たりにした。 アジャイルメソッド(和訳)である。アジャイルメソッドはデータベースの設計に対していくつかの全く新しく重大な要求を投げかけることとなった。要求の核心にあるのは進化的設計(evolutionary design)だ。アジャイルメソッドを採用するプロジェクトにおいては、システム要件を事前に凍結させることは不可能だということを前提にしなければならない。つまり詳細な設計フェイズをプロジェクトの開始時に置くことは現実的ではなくなる。設計はイテレーションが進むに従って進化しなければならないのだ。アジャイルメソッド、特にXPには、進化的設計を現実的に行うためのプラクティスがある。
規模の大きいデータベースを伴うシステムに対して進化的設計が可能であるかどうかをほとんどの人が疑問視していた。実際何人もの人が進化的設計は不可能だったと私たちに語った。-- このことは
この文章は私たちがこのような「不可能なこと」を行うために使用したプラクティスを説明する。私たちはデータベースの進化的設計にまつわる問題を完全に解決したとは言わないが、ここで説明する技法は多くの人にとって有用だと私たちは考えている。
変化に対応する
アジャイルメソッドの主要な特徴のひとつは変化に対する姿勢だ。大概のソフトウェア開発プロセスの考え方は、早期に仕様を理解し、その仕様を承認し、その仕様をもとに設計し、その設計を承認し、構築に進むことである。この考えはしばしばウォーターフォールとして(たいてい嘲笑と共に)引き合いに出される計画駆動のサイクルだ。
このようなアプローチは高価な先行投資を行うことによって変化を最小にすることを目指している。先行作業が終了した後となっては、変化は重大な問題を引き起こす。つまりこのような先行投資型のアプローチは仕様が変化すると困難に陥り、仕様の揺れはこのようなプロセスに対する大きな問題となる。
アジャイルなプロセスは変化に対して異なったアプローチをとる。アジャイルプロセスは変化を抱擁(embrace change)しようと努め、プロジェクトの後期になってさえも仕様の変更を可能にする。もちろん変更は管理されるものの、プロセスのとる姿勢は変更を可能な限り可能にすることだ。アジャイルプロセスの姿勢の一側面は、多くのプロジェクトが抱える「仕様というものが本来持っている不安定さ」という問題に対応するものであり、また競争圧力に対応して変化していくダイナミックなビジネス環境をよりよくサポートすることである。
変化に対応するためには、設計に対して異なる姿勢をとる必要がある。設計を構築の前にほとんど終了するフェイズと捉えるのではなく、設計を構築、テスト、ときには納入(delivery)と同時に進むプロセスと考えなければならない。これが計画的設計と進化的設計の違いである。アジャイルメソッドの重要な貢献のひとつは進化的設計を着実に行うためのプラクティスを編み出したことだ。アジャイルメソッドの技法によって、設計を先行して行わなかった結果しばしば生じる典型的なカオス状態に陥ることなく、進化的設計をコントロールして着実に実践することができる。
このアプローチにおける重要な点はイテレーティブな開発だ。イテレーティブな開発とはプロジェクトの期間中にソフトウェアの開発サイクルを何回転もさせるということである。アジャイルメソッドは各イテレーションで開発サイクルを一回転させる。イテレーションは最終的な製品の仕様の一部分を満たした、動作し、テストされ、結合されたコードと共に終了する。イテレーションの期間は一週間から二ヶ月と短く、短ければ短いほど良い。
アジャイルメソッドが実用と関心の下で広まっていく際に、最大級の疑問となったのはどうやってデータベースに対して進化的設計を行うかということだった。多くの人はデータベースの設計には先行設計が絶対に必要だと考えている。開発の後期でデータベースのスキーマに変更を加えるということは開発中のソフトウェアをズタズタにしかねないし、納入後のスキーマ変更に至ってはデータの移行という頭の痛い問題を引き起こす。
ここ三年私たちはAtlasと呼ばれる大規模プロジェクトに従事し、進化的設計をデータベースに対して施すことに成功した。プロジェクトでは世界に散らばる拠点(US、オーストラリア、インド)に100人程度の人間が従事していた。50万行ほどのコードと200を超えるテーブルがあった。データベースはまず開発初期の一年半の間進化(evolve)し、多数の顧客に対して製品として納入する時期に至るまで進化を続けた。このプロジェクトを開始するにあたって私たちはまずイテレーション期間を一ヶ月から始めたが、数ヵ月後に二週間のイテレーション期間に変更した。二週間のイテレーションのほうが上手く機能した。この文章で説明する技法は私たち(より正確にはPramod)がこのようなプロジェクトを機能させるために使用したものである。
私たちのプロジェクトが始まって以来、これらの技法を私たちのプロジェクトにさらに多く適用し、様々なケースから様々な経験を積んできた。また、他のアジャイルなプロジェクトのインスピレーション、アイデアおよび経験が参考になった。
制限事項
技法の紹介に進む前に、データベースの進化的設計に関する問題のすべてを解いているのではないことを示しておく必要があるだろう。特に:
- 私たちは単一のアプリケーションに対するデータベースを構築したのであり、複数のデータベースを統合する統合データベース(integration database)を構築したのではない。
- 私たちはデータベースを24時間稼動させる必要がなかった。
私たちはこれらの問題を本質的に解決不可能なものだとは(たとえ多くの人が私たちがこの問題を解けなかったのだと考えたとしても)考えていない。しかし問題が解けるまでは、私たちはこれらの問題まで解決できるとは言わないことにする。
プラクティス集
データベースの進化的設計へのアプローチは一握りの重要なプラクティスにかかっている。
DBAは開発者と密接に協力し合う
アジャイルメソッドの教義のひとつに、異なるスキルとバックグラウンドを持った人たちが密接に協力し合うべきだというものがある。形式的な会議やドキュメントを主な手段としてコミュニケーションをとり続けることは出来ない。かわりに要求されることは常に共に話し掛け、共に働くことだ。すべての人がこの教義の適用範囲に入る: 分析者、プロジェクトマネージャ、ドメインエキスパート、開発者...そしてDBAも。
開発者が取り組むタスクは潜在的にDBAの助力を必要としている。あるひとつの開発タスクがデータベースのスキーマの大きな変更を必要とするかどうかを開発者とDBAが共に考慮しなければならない。スキーマ変更が必要である場合、開発者はどうやって変更を施すかを決めるためにDBAと意見を交換する必要がある。その開発者はどういった新しい機能が必要なのか知っており、DBAはアプリケーション内のデータに関して広い視野を持っているからだ。
開発者と意見を交換するためには、DBAは近くにいて利用できる存在となるように心掛けなければならない。開発者が気軽にひょいと現れて少しの間質問をできるようにしなさい。DBAと開発者が互いに近くに座り容易に会える手段を講じなさい。アプリケーションの設計セッションにDBAが参加するのを容易にしなさい。多くのプロジェクトで、DBAと開発対象の機能の間に壁が存在するのを見てきた。この壁はデータベースの進化的設計を機能させるためには打ち壊されなければならない。
全員が自分のデータベースインスタンスを保有する
進化的設計は人々が実際に作ってみることによって学ぶことを認識している。このことはプログラミングでは、開発者が特定の機能をどうやって実装するかを実験し、良いと思った案に落ち着けるまで何通りかを試みることにあたる。データベースの設計も同じようにできるはずだ。つまりすべての開発者は他の人に影響を及ぼさずに実験を行うために自分のサンドボックス(実験空間)を持つことが重要となる。
多くのエキスパートDBAは複数のデータベースのことを実際に扱うには難しすぎるものとして忌み嫌っている。しかし私たちは100を超えるデータベースインスタンスを管理することはそれほど難しくはないことを発見した。重要なことはファイルを扱うようにデータベースを扱えるツールを持つことだ。
開発者は共有マスターに頻繁に結合する
手元で実験を繰り返すことができるとはいえ、開発者はその実験結果を頻繁に還元することを忘れてはならない。アプリケーション開発には開発の中心となる共有マスターデータベース(shared master database)が必要だ。開発者はタスクを開始する際にマスターを自分のワークスペースにコピーし、編集し、その変更結果をマスターに還元する。経験則として、開発者は最低一日一回はマスターとの結合を行うべきだというものがある。
例を挙げよう。Mikeは開発タスクを午前10時に始める(Mikeが出勤してきたのはもっと前の時間だと想定する)。このタスクの一環として彼はデータベーススキーマの変更が必要になった。変更がカラムの追加のような簡単なものならば、彼はどうやって変更を施すかを自力で判断する。それと同時にMikeは、必要とするカラムがデータベース上にまだ無いことをデータディクショナリ(後述)を使って確認する。変更がもっと複雑なものならばDBAを捕まえMikeが考えている変更について話す。
準備が整ったらMikeはデータベースのマスターのコピーをとる。これで彼はスキーマとコードを自由に変更することができる。サンドボックスの中ならばどんな変更でも他の人に影響を与えることはない。ある時点で、例えば午後3時頃に、Mikeはプログラミングはまだ終了していないが、データベースをどう変更するべきかについては満足な結果が得られたとしよう。この時点で彼はDBAを捕まえ、変更について話す。ここでDBAはMikeがまだ考えていなかったような問題点を挙げることができる。大抵の場合はすべて問題なく、DBAは変更(後で述べるような、ひとつ以上のデータベースのリファクタリング)を行うために立ち去る。DBAは直ちに変更を施す(変更が破壊的なものでない限り-これも後で説明する)。Mikeは作業を続け、DBAがマスターに変更を施した後にはいつでも好きなときにコードをコミットすることができる。
ここで説明したことがソースコード管理に適用される継続的インテグレーション(和訳)というプラクティスに似ていることにあなたは気づくかもしれない。実際これはデータベースを他のコードと同様に扱うことを意味する。マスターデータベースをソースコードと同様に構成管理の下に置くのである。ビルドが成功したときはいつでも、データベースはコードと共に構成管理ツールにチェックインされる。こうすることによってデータベースとコードの完全でかつ同期化された履歴を残すことができる。
ソースコードに関しては結合の難しさの大部分を構成管理ツールが対処してくれるが、データベースに対してはもう少し私たちの努力が必要となる。データベースに対するいかなる変更も自動化されたリファクタリング(これも後述する)のように正確に行われる必要があり、加えてDBAはデータベースに対するすべての変更を把握し、データベーススキーマ全体に上手くフィットするかどうか保証する必要がある。これらのことをスムーズに行うためには、大きな変更が結合の際に突然出現するべきではない - だからDBAと開発者が密接に協力し合う必要があるのだ。
私たちは結合を頻繁に行うことを推奨する。これは小さな結合を頻繁に行うほうが大きな結合をまれに行うよりも容易だということがわかったからである。結合の難しさは結合の規模に従って指数関数的に増加するようなのだ。したがって多くの人の直感には反するが、実際には沢山の小さな変更の方が行いやすい。同じ効果がソースコード管理に関するソフトウェア構成管理のコミュニティからも報告されている。
スキーマとテストデータから成るデータベース
私たちがここでデータベースを語るとき、それはスキーマのみを意味しているのではなく、当然沢山あるデータをも意味している。ここで言うデータとはアプリケーションのために用意された一般的なもの、たとえばお決まりの合衆国各州のリストや、何人かの顧客を模したサンプルテストデータ等だ。
データがデータベースに入っている理由はさまざまだが、そのひとつにテストがある。私たちは、自動化された大量のテストを使用してアプリケーション開発を安定させる手法を熱烈に支持している。大量のテストはアジャイルメソッドの一般的なアプローチだ。これらのテストを有効に機能させるためには、サンプルデータの入ったデータベースで作業を行うのがよい。そうすれば実行前にデータが入っていることを前提にテストを書くことができる。
このサンプルデータによって、コードをテストするだけではなく、データベースのスキーマを変更した際の移行作業もテストすることも可能になる。サンプルデータによって、スキーマ変更の際にはサンプルデータの対処も確実に行わざるを得なくなるからだ。
ほとんどのプロジェクトにおいて、でたらめなサンプルデータが使用されるのを目にしてきた。しかしいくつかのプロジェクトでは実データをサンプルとして使用していた。実データを使用していた場合では、データはレガシーシステムから自動化されたデータ移行スクリプトで抽出されていた。当然だがあなたは今すぐにすべてのデータを移行する必要はない。初期のイテレーションの場合にはデータベースの一部のみが構築されるからだ。しかし重要なことは移行スクリプトをアプリケーションやデータベースと同様にイテレーティブに開発するという考え方だ。このことは早期に移行の問題を洗い出すだけではない。まずドメインエキスパートにとってはデータが見慣れたものであるゆえに、成長していくシステムと共に作業しやすくなる。そして実データはしばしば例外ケースの早期発見に役立ち、データベースとアプリケーションの設計に関するリスクを軽減する。よって最終的に私たちは実データを一番最初のイテレーションから導入するよう努力すべきだという見解を得た。
すべての変更でデータベースのリファクタリングになる
リファクタリングを一言で表すと既存のコードを変更するための規律正しくコントロールされた技法ということになる。コードのリファクタリングと同じように、私たちは規律正しくコントロールされた方法でデータベースを変更することができるデータベースのリファクタリングをいくつか発見した。
データベースのリファクタリングがコードのリファクタリングと大きく異なる点は、同時に行うべき三つの変更が含まれていることだ。
- データベーススキーマの変更
- データベース内のデータの移行
- データベースアクセスコードの変更
従ってデータベースのリファクタリングについて論じるときには常にこれらの変更要素すべてについて論じなければならない。そしてこれらの変更要素すべてを他のリファクタリングの前に行うことを保証しなければならない。
私たちはまだデータベースのリファクタリングの文章化の途中である。そのためまだ内容について詳細に語ることはできないが、何点か指摘できる点がある。まずコードに対するリファクタリングのように、データベースのリファクタリングは規模が小さい。また、非常に小さい変更を連鎖させるというコードのリファクタリングのコンセプトはデータベースでも同様だ。そしてデータベースのリファクタリングには上記の三つの要素があるため、変更を小さく保つことはコードのリファクタリングよりもさらに重要だ。
データベースのリファクタリングの多く(例えばカラムの追加)はシステム内のデータベースアクセスコードのすべてを更新する必要はない。もしカラム追加に気づかずにコードが新しいスキーマを使用していても、そのカラムが使われないというだけだ。しかし、こううまくはいかない変更も多い。私たちはこのような変更を「破壊的な変更」と呼ぶ。例えばNULLを許すカラムをNULLを許さないように変更するというような変更だ。
破壊的な変更に対しては、破壊の度合いに応じて少し慎重になる必要がある。比較的小さい「破壊的な変更」の例は例えばNULLを許すカラムをNULLを許さないように変更することだ。このケースではすぐに変更に取り掛かることもできる。リファクタリングはデータベース内にNULLで入っているデータを取り扱うものになるだろう。大抵の場合この変更を気にかける開発者は変更の依頼を行った開発者一人であり、その開発者はデータベースのマッピングコードを更新するだろう。結果としてこの更新は他人のコードを壊すことはなく、もし何かの間違いで壊すことがあっても、ビルドしてテストを行う際にすぐに見つかる。(私たちの大規模プロジェクトではデータベースの変更のために一週間の猶予期間を設けている)
しかし、使用頻度の高いテーブルを二つに分割することなどは幾分複雑な変更の例だ。この場合には全員に変更が行われることを周知することが重要となる。周知を行えば彼らは変更に備えることができるからだ。加えて言うなら、変更を施すまでの安全期間を設けることも検討する価値があるだろう。(私たちはこのような変更を新しいイテレーションの開始時まで延ばす。 - 私たちは二週間以内のイテレーションを好む)
重要なことは、行おうとする変更にふさわしい作業手順を選択することである。確証が持てないときには変更作業をより簡単にするよう心掛けるべきだ。私たちの経験上、変更によって痛い目にあう頻度は多くの人が考えるほど多くはない。全システムを管理する強力な構成管理ツールの下にあれば、もし最悪の事態が起こっても元に戻すのは難しいことではない。
リファクタリングを自動化する
コードの世界では、代表的なリファクタリングの数々を自動化するツールが複数のプログラミング言語上で存在する。データベースにとっても、このような自動化ツールは少なくともスキーマ変更とデータ移行において必要不可欠となる。
最終的にはすべてのデータベースリファクタリングはSQLのDDL(スキーマ変更用)とDML(データ移行用)の形として自動化される。データベースの変更は絶対に手で行われることがあってはならず、手で行うかわりに変更を行う小さいSQLスクリプトを実行することによってマスターデータベースに適用される。
リファクタリングが終わったらスクリプトを捨てずに保存しておく。リファクタリングによるデータベースへのすべての変更の変更履歴(change log)を作るためだ。変更履歴スクリプト集を作成しておけば、マスターをローカルにコピーしてから行われた変更履歴スクリプトをすべて実行することによって、どのデータベースのインスタンスでも最新のマスターの状態に更新することができる。
自動化された変更を順序付けるという機能は、開発における継続的インテグレーションのプロセスと、納品されたデータベースを新しいリリースに対応させる移行作業の両者にとって欠かすことのできないものだ。
通常のイテレーション中には本番データベース(production databases)に変更を施さない。リリースを行う際、つまり毎回のイテレーションの最後に、前回のリリース以降のデータベースのリファクタリングの変更履歴すべてを適用する。これは大きな変更であり、私たちが今までで唯一アプリケーションをオフラインにすることで対応したものとなった(私たちは、24時間稼動の環境の中で変更履歴すべてを適用することに対していくつかアイデアがあるが、このときはまだ行う必要がなかった)。また、運用中のデータベースに適用する前に移行スキーマをテストすることもいい考えといえるだろう。いままでのところこのやりかたは非常に上手くいっている。データベースのすべての変更を小さく単純な変更に分割することによって、非常に大きな変更を本番データベースに対してトラブルなく行うことができた。
一つ一つのリファクタリングにおいて、順方向の変更を自動化するだけでなく逆方向の変更を自動化することも考えるべきである。逆方向の変更を自動化することができれば、データベースに対する変更の取り消しも自動化することができる。私たちにはこの自動化がまだ必要なかったため行っていないが、逆方向の変更の自動化は順方向の自動化と同様の基本原則といえる。
(この他に私たちが行ったことは、古いバージョンのアプリケーションを更新されたバージョンのデータベースに対してサポートすることだった。これは互換性レイヤー(compatibility layer)を書くことで対応した。互換性レイヤーによって、アプリケーションに実際には新しいバージョンのデータベースと通信しているにもかかわらず古いバージョンのデータベースと通信しているように思い込ませることが可能になる。)
すべての開発者のデータベースに変更を自動的に適用する
誰であろうと、変更を行いマスターを更新することは一向に構わない。しかしマスターが変更されたことはどうやって知ればいいのだろうか。ソースコードを扱う一般的な継続的インテグレーションの環境では、開発者はコミットを行う前にマスターから最新版をチェックアウトする。この方法によって開発者はマスターにコミットする前に自分のマシンでビルドに関する問題を把握することができる。データベースで同じことができないという理由はない。しかし、私たちはより良い方法を見つけた。
変更がデータベースのマスターに行われるときはいつでも、私たちはプロジェクト全員のデータベースを自動的に更新する。マスターの更新に使用されているリファクタリングスクリプトと同じスクリプトが全員のデータベースを更新する。この方法のことを話すとき、聞いた人が大抵心配するのは開発者のデータベースを裏で自動的に更新することが問題を起こすのではないかということだ。しかし、この方法が実にうまくいくことがわかったのだ。
ただしこの方法はネットワークに接続している状態でないと機能しない。例えば飛行機の中などでネットワークにつながっていない場合には、仕事場に戻ってきたときに手でマスターと同期をとらなければならない。
データベースアクセスコードを明確に分離する
データベースリファクタリングの影響を把握するためには、データベースがアプリケーションによってどのように使われているかを調べることが可能でなければならない。SQLがコード達の中に乱雑に散らばっているならば、調査は非常に困難になる。つまり、データベースがどこでどのように使用されているかを明らかにするために、明確なデータベースアクセス層を設けることが重要になる。データベースアクセス層を設ける際にはPofEAAの中からデータソースアーキテクチャパターンのどれかに従うことを勧める。
明確なデータベースアクセス層を設けることで、いくつもの良い作用があらわれる。データベースアクセス層は開発者にとってデータベースを操作するためにSQLの知識が必要になる範囲を最小化する。これでSQLが得意ではない開発者がより参加しやすくなる。一方DBAにとっては、データベースアクセス層はデータベースがどのように使われているかを確認するために調べるべき明確なコード群となる。これでインデックスの定義やデータベースの最適化、またパフォーマンスを出すためにどうやってSQLを書き直すかを考えることなどが容易になる。データベースアクセス層は、データベースがどのように使用されているかについてDBAがより深く理解することを可能にする。
変化形
他のプラクティス集と同様に、この文章で述べられているプラクティスもあなたのまわりの特定の状況に対応して変化するべきだ。このプラクティス集はまだ生まれて間もないため、私たちは多くの変化形に出会ってはいないが、ここにいくつかを挙げる。
複数のデータベースの血統を維持する
単純なプロジェクトはリポジトリ内にひとつのデータベースマスターがあるだけでも成立するが、もう少し複雑なプロジェクトではプロジェクト用のデータベースを複数の種類サポートする必要がある。私たちはこれをデータベースの血統(lineage)と呼ぶ。納品のためにアプリケーションのブランチを作成しなければならないときに、私たちは新しい血統を作成する可能性がある。新しい血統の作成はアプリケーションのソースコードをブランチさせることと本質的にはほとんど同じことである。アプリケーションのブランチと多少異なる点は、通常と異なるサンプルデータを必要とするとき(例えばパフォーマンステストのように大量のデータを必要とする場合)にも血統を作成するという点だ。
開発者がマスターのコピーを取るときには、どの血統を編集するのかを登録しなければならない。DBAが特定の血統のマスターに変更を適用するときに、その血統に登録された開発者のデータベースも更新される。
DBAは必要ない
DBAは必要ないなどと聞くと仕事が増えると考えるかもしれない。しかし実際には膨大なマンパワーを必要とはしない。Atlasプロジェクトでは30人余りの開発者が従事し、QA、分析者、管理者も含む総チームサイズは100人近かった。所定の日に、私たちは様々な血統を100近い端末にコピーするが、この作業は常勤のDBA一人(Pramod)および兼業して手伝う開発者二人を必要としただけだった。
小さなプロジェクトにおいては、このような体制さえ必要ない。これらの技法を多くの小規模プロジェクト(12人前後)で使用してきたが、これらのプロジェクトでは常勤のDBAを必要としなかった。代りにDBに関心のある開発者にDBAの仕事を兼業してもらうように依頼した。
DBAをそれほど必要としなかった理由は自動化にある。すべての作業を自動化しようと努力していれば、より少ない人数でより多くの仕事を行うことができる。
ツール
この文章で説明してきたようなことを実行するには大量の繰り返し作業が必要となる。ありがたいことに、ソフトウェア開発において繰り返し作業に出くわすときはいつでも、そこが自動化に最適な場所となる。その結果私たちは、作業の自動化のために多くのツールを開発した。その大部分は単純なツールだ。
最も価値ある自動化ツールのひとつに、一般的なデータベース作業のための簡単なスクリプト集がある。
- ユーザデータベースを最新のマスターの状態までアップデートする
- 新規ユーザを作成する
- データベーススキーマをコピーする。例えばSueが彼女のデータベースにバグを発見したとき、MikeはSueのデータベースをコピーしアプリケーションをデバッグすることができる
- データベースを移動する。たとえばワークステーションから他のワークステーションへ移動する。これは本質的にはデータベースのコピーと削除のセットである
- ユーザを削除する
- ユーザデータベースをエクスポートする。この機能でチームメンバーは作業中のデータベースのオフラインバックアップをとることができる
- ユーザデータベースをインポートする。チームメンバーがデータベースのバックアップを持っているならば、彼らはバックアップをインポートし新しいスキーマを作成することができる
- マスターデータベースのバックアップ(ベースラインと呼ばれる)をエクスポートする。これはユーザデータベースのエクスポートの特殊例だ
- 任意のスキーマの差分レポートを作成する。この機能でMikeが彼のデータベースとSueのデータベースの間で構造的な差分を見ることができる
- マスターデータベースとの差分レポートを作成する。この機能で開発者は自分のデータベースとマスターデータベースを比較することができる
- すべてのユーザをリストする
分析者や品質保証チームは、データベースの中のテストデータを見たり、テストデータを簡単に変更したりできなければならない。これらの作業を簡単にするために私たちはVBAスクリプトでExcelアプリケーションを作成した。このExcelアプリケーションはデータベースからデータをExcelファイルに落とし、ファイルを編集し、元のデータベースに反映することができる。他にもデータベースの内容を見たり編集することが可能なツールが存在するが、Excelには多くの人が慣れているのでうまく機能した。
すべてのプロジェクトメンバーはデータベースの設計を容易に調べることができなければならない。容易に調べることが可能になれば、現在どんなテーブルが利用できるのか、またそれらのテーブルががどのように使われているのかを知ることができる。私たちはこの用途のためにデータベースのメタデータを検索するサーブレットで動くHTMLベースのツールを提供した。このツールを使用すれば、例えばMikeは、カラムをテーブルに加える前に追加しようとしているカラムが既にあるかどうかをテーブルやカラムのメタデータを検索して調べることができる。私たちはデータモデリングにERwinを使用したが、このERwinのデータも引き出して私たちのメタデータテーブルに入れた。
更なるステップと情報
この文章は、データベースデザインの進化的設計に関する決定版では断じてない。私たちはここで説明した技法を統合データベース、24時間稼動、さらに私たちがまだぶつかっていない他の問題領域まで広げることができるかどうか見てみたいと考えている。
あなたがデータベースの進化的設計についてもっと知りたい、もしくはあなた自身の経験について話したいと思うならば、Pramodが始めたアジャイルデータベースのヤフーegroupを見てほしい。またPramodはいろいろなカンファレンスでこの技法について話し始めているので、あなたは直接彼と話す機会を得るかもしれない。もちろん、私たちもデータベースの進化的設計に関してコンサルティングを行っていく。
Copyright Martin Fowler, all rights reserved
翻訳: 和田(t-wada@tech.email.ne.jp) $Revision: 1.11 $ $Date: 2003/10/27 07:24:59 $