サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

ソフトウェア開発 旧館より

テーブル設計の指針(備忘録)

投稿日:2007年11月29日 更新日:


最近、DB設計やデータモデリング等のDB周辺について集中して触れることがあったのでテーブル設計における指針を備忘録として書いておきます。

サロゲートキーとナチュラルキー

主キーの設定時に大きく2つの設計指針があります。

1つは顧客マスタにおける顧客ID、商品マスタにおける商品番号、また発注テーブルにおける発注番号等、ビジネス(業務)上で意味を持ち、自然に一意となる値を主キーに設定する設計指針です。
これを「ナチュラルキー (natural key)」と呼びます。

もう1つは、システム内部でレコードを一意とする為に採番(その多くは自動採番)する方法です。
この方法で取得した主キーを「サロゲートキー(surrogate key)」とか「人工キー(artificial key)」と呼びます。
※参考:「いざRuby on Railsでプロトタイピング」

RubyOnRailsで使用するActiveRecordではサロゲートキーをある意味前提になっています(そのパフォーマンスを最大限に発揮できます)。

テーブル設計上、どっちが良いか…ですが、私はお客様の要望が無ければサロゲートキーを採用します。

ナチュラルキーの代表的なものである顧客IDや社員番号、商品番号等は先程も書いたようにお客様(直接でなく間接的な意味も含め)が決めたものです。
そしてその決め方、不変である保証はいつ(お客様の都合により)変わるともしれないのです。

そういう外部(ここでいうお客様)に決定要因を持たれていることは、設計において(またプロジェクト全体の視点からも)リスクが高くなります。「自分の預かり知らぬところ」「手が出せないどうしようもないところ」だからです。

一方、サロゲートキー方式の場合、主キーはシステムの表面上に現れないので、仕様変更にも比較的柔軟に対応できます。
※参考:「システムの寿命はコードで決まる!」

システムテーブルの使い方

会社名や運用日付、伝票Noカウンター等を保持する方法にシステムテーブルを作成して保持する設計指針があります。
通常、このシステムテーブルは1レコードのみでレコードの増減はありえないのですが、この時、ちょっと拡張性を考えて、視野を広く持てば複数レコードとなっても良いように主キーを設定します。

将来的に同一システム上で複数部署、会社等に横展開しやすくする為です。

※参考:「業務システムモデリング練習帳

セットの応用

テーブル設計には直接関係ないのですが、業務分析をうまくテーブル設計に反映させましょうという内容です。

例えば薬や部品等、「Aを注文する際には必ずBもCも注文するよ」というセット(組合せ)があることが多かったりします。で、普通のシステムの注文機能だとA,B,Cは3回注文する品を選ぶ必要があります。

Aを選べばB,Cにもデフォルトの選択がされていれば現場は助かると思いませんか?

こういう内容は普通にヒアリングしているだけでは出てこない内容です(おそらくそもそも要求事項として上がって来ないでしょう)。
ただ、使用するユーザ(=現場)にとっては面倒なことだったりして、運用テストの段階で仕様追加という名前で出てくることでもあります。そしてこの要望を実現しようとすれば、その組合せ情報を保持する関連テーブルが必要だったりして、すぐには対応できません。
ですので、業務分析、ヒヤリング時に、この視点でも考えてみて、適用できそうだったらこちらから提案できれば良いと思います。

インデックスについて

インデックスをシステム構築の後半戦…下流工程…下手をすると結合テスト、運用テストで初めて設定することがあります。

そのきっかけが「パフォーマンスが出ない」という現象です。
定数的に表現されれば良いのですが、たいてい「何となく遅い」と言われることが多いものです。まぁこれは要件定義段階で非機能要求を決めていないのが元凶ですが…。

インデックス設計は設計フェーズで行う必要があります。
データの件数、増加量、参照系/更新系等を基本設計(外部設計)で行い、それに見合うように内部設計でテーブル定義を行う必要があります。

インデックスは比較的簡単に行え、効果も高いことが多い(費用対効果が高い)のですが、逆効果になることもあるので注意が必要です。

テーブル設計には「絶対的」正解というものは無いと思います。
ただ、定石はあり、「実装するのに楽だから」とか検討が浅すぎた等で後々、保守開発、機能追加で本来(その工数を前払いしていればもっと少なくて済んだ)不要な工数を使っているように思います。

これは結局、お客様にとっての不利益になり、その工数の妥当性があっても「構築時にキチッと考えておいてよ」とお客様の不満(不信感)のタネになります。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via Visualhunt.com

-ソフトウェア開発, 旧館より

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

昔は良かった?

年上の人と話すと、割と誰しもが感じる「昔は~だった」について、「自分もこうなったらあかんな」と自戒を込めて書きます。 年上の方と話していると、時々「昔は…だった」という話が出てきます。 昔の話を聞ける …

プロジェクトに途中から入る難しさ

開発プロジェクトの立ち上がりではなく、途中から参加することはどれくらいの頻度であるでしょうか? また、それはどのあたりから参加することが多いでしょうか? 開発プロセスがウォーターフォールの場合、要件定 …

チケットの粒度が難しい

過去のメモを整理していたところ、2年程前のプロジェクトで悩んでいた時に書いたメモが出てきたので備忘録としてアップしておきます。 悩んでいたこと RedmineやTracなどのITS(Issue Tra …

聖人君子はムリでも…

街中で見かけた光景で、ふと思ったことです。 車通りも滅多にない幅の狭い道路、でも信号と横断歩道はあります。 さて、徒歩or自転車でその道路を渡ろうとします(車は影も形もありません)。 が、横断歩道の信 …

フリカエリ

[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」と「見える化」ともう1つ「フリカエリ」について考えることがありました。 今のチーム(約2年)では原則、(Scrumの)イテレーション毎にフリカ …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。