Technology へようこそ
ここは技術者の「経験」と「ノウハウ」のブログです
2005年09月12日 |
DBエンジニアとDB設計の話 |
| システム開発。ありていに言うならコンサルタントが要件を掘り起こし、SEが 業務要件をまとめてプログラマがPGを作成し、各種のテストを行い、納品した システムをユーザが運用する。 ちょっとまってください。 DB設計を行うとき、DBエンジニア（SEが兼務することもあるでしょうが・・・）に 与えられる時間はいかほどでしょうか？ 大きなシステムを開発する際でも、DBの設計にかけられる時間は非常に少ない、 または何かの片手間で行われるのがほとんどではないでしょうか？ DB設計はシステム開発を行う際、アプリケーション設計と並ぶ、いや、それ以上 に重要な作業だと思うのです。 しかし、今日に至ってもDB設計は軽視されています。 かくいう私もDB設計を行うとき、充分な時間を与えられた記憶はありません。 DB設計が適切であればアプリケーションはシンプルになります。（過大な機能を 無理やり実装する場合は別ですが。）また、データというものは時の移り変わり に対してそう変わっていくものではありません。これに着目したのがみなさんよく ご存知の「データ指向設計」です。 システム開発の工程のなかで、ユーザの要件を理論的に表現する必要のある最初 の関門がDB設計だと思うのです。 「優れたDB設計を見ればシステムがわかる」というのが私の持論です。 私がDB設計を行うときの3種の神器は ・項目辞書 ・ERダイアグラム ・コード定義表 です。 項目辞書はDBのテーブル名と項目名、関数名、ストアードプロシージャ名など のオブジェクト名称を決めるための辞書です。 たとえば、売上は SLS（salesから）、金額はAMT（amountから）というように 決めておきます。すると、項目名「売上金額」は SLSAMT となるわけです。 これを実践すると単純なコーディングミスが激減します。 ERダイアグラムは私の場合、少々誇大解釈していて、拡張ERとも少し異なる形式 のものを作成します。実際のテーブルの項目が一覧できることと、アプリケーシ ョンの実装を行う際、プログラマから好評なので、必ず作るようにしています。 項目名の一覧にも使えますし、PKの項目も参照できます。 コード定義表はコード設計じゃないの？といわれるかもしれませんが、私はDB設計 をしながらコード設計を並行して行うことが多いのでDB設計を行うときは必須です。 特に内部コード（外から見えないコード）はここで桁数とかその意味を決めておか ないと後で苦労します。 DB設計が適切に行われると後の工程が非常に楽です。 事実、私の経験したプロジェクトで、DB設計がうまくいった（と思われる）プロ ジェクトはすべてハッピーエンドで終了しています。 あなたが関わったプロジェクトはどうですか？ |
| この記事に対するコメント |
|
短縮形を組み合わせてヘンテコリンな造語を作るより、 そのまま日本語にしとくか、完全な英語にしろよ。 項目辞書とか項目長に制限があった時代の遺物だろ？
【2009/12/16 01:13】
URL | A #- [ 編集]
|
| この記事に対するコメントの投稿 |
