none
テーブル設計のテクニックについて RRS feed

  • 質問

  • これまでクライアントサイドのプログラミング中心できたこともあり、あまりサーバーサイドやDB設計をした経験がないのですが、最近になって基幹系のDB周りの業務も担当するようになってきました。
    直近では、すでにあるTBLに削除のフラグのような列があるのを見たとき、最初は何に使うのかわからなかったのですが、インターネットで色々調べるうちに"論理削除"というやり方があるのかと知ったぐらいです。現状がこんな状態なのですが、識者の方に質問があります。

    1.登録日時・ユーザー、更新日時・ユーザーのカラムについて
    2.TBLやDB設計について現場で利用するようなテクニックが記載された本やリソースについて

    1.登録日時・ユーザー、更新日時・ユーザーのカラムについて
    参考にするために他システムのTBL定義などを見ているのですが、多くのTBLにレコードの登録日時と登録ユーザー、レコードの更新日時と更新ユーザーという列が設けられています。
    私の想像だと、単純にそのレコードがいつINSERTされたのか、だれによってなのか、場合によってはいつ更新されたか、もしくは更新されていなければ、誰も更新していないということを保証するために
    あるのかといったところで止まってしまうのですが、これ以外にも用途などはあるのでしょうか?ちょっとわかりにくいかもしれませんが、どういったケースのときにこういうカラムがあると、便利といった事例があれば教えていただきたいです。

    2.TBLやDB設計について現場で利用するようなテクニックが記載された本やリソースについて
    いまのところ、論理削除というやり方や1.の内容ぐらいしか知らないのですが、他にもこういうやり方があるので知っておくとよいというものがあれば、ぜひ教えていただきたいと思います。
    また、そういったものがまとまった本、DB・TBL設計において一度は読んでおくといい本やリソースなどがあれば知りたいです。
    2009年11月24日 13:56

回答

  • 2.TBLやDB設計について現場で利用するようなテクニックが記載された本やリソースについて
    いまのところ、論理削除というやり方や1.の内容ぐらいしか知らないのですが、他にもこういうやり方があるので知っておくとよいというものがあれば、ぜひ教えていただきたいと思います。
    また、そういったものがまとまった本、DB・TBL設計において一度は読んでおくといい本やリソースなどがあれば知りたいです。


    参考になるか全く判りませんが・・・
    この質問を聞いてかなり懐かしさを感じたので、一応思いつくまま書いてみます。

    むか~し、まだ DAO(データ中心アプローチ)が全盛?だったころ、以下の本を買って勉強したことがあります。

    失敗のないシステム開発入門

    著者の加藤さんにはコンサルに来て頂いて、直にDB設計のノウハウを教授いただいたものです。

    当時はこの本の影響を受けて正規化に拘りまくり、テーブルを全て第五正規化までしておりました。
    おかげで確かに仕様変更には強いDB 構造になったのですが、いまとなっては正規化をし過ぎたため

    1.更新が面倒である。
    2.結合が複雑になりすぎる。

    嫌いがあることは否めません。やはり必要に応じて正規化崩しも必要でした。

    またオブジェクト指向に関しては

    「データにメソッドを持たせたものがオブジェクト」

    と言い切られておりますが、今となっては残念ながらその考え方は通用しないですね。(^ω^;

    ただこの頃より ER 図を作成する必要性を強烈に感じたので
    会社が買ってくれないため自腹で Visio を購入し、
    DB 設計の際は必ず Visio を使って ER 図を起こすようになりました。

    #ERWin は個人じゃ高すぎて手が出ない・・・(-ω-;

    業務別データベース設計のためのデータモデリング入門

    この本もかなりお世話になった本の一つです。

    テーブル設計のコツというか、かなり DB 設計の落とし所についてノウハウを明かしています。
    難点は独自の ER 図を使っているところ。普通の ER図に慣れていると
    渡辺式 ER 図は理解しにくいのですが、慣れてくると意図が明確に読めるようになります。
    でも後半は amazon のレビューどおり確かに読みにくいかも。

    実践的データモデリング入門

    この本はまだ読んでませんが、レビューを見る限りなかなか面白そうです。

    昔はデータモデリングに関する書籍ってホント少なかったのですが、
    DB Magazine がこの手の本を出すようになってから、かなりデータモデリングに関する書籍が増えてきたようですね。
    amazon のレビューを頼りに2~3冊購入して読み比べてみるのもいいかも知れません。
    • 回答としてマーク CrimsonPork 2009年11月25日 11:39
    2009年11月25日 6:20

すべての返信

  • 2.TBLやDB設計について現場で利用するようなテクニックが記載された本やリソースについて
    いまのところ、論理削除というやり方や1.の内容ぐらいしか知らないのですが、他にもこういうやり方があるので知っておくとよいというものがあれば、ぜひ教えていただきたいと思います。
    また、そういったものがまとまった本、DB・TBL設計において一度は読んでおくといい本やリソースなどがあれば知りたいです。


    参考になるか全く判りませんが・・・
    この質問を聞いてかなり懐かしさを感じたので、一応思いつくまま書いてみます。

    むか~し、まだ DAO(データ中心アプローチ)が全盛?だったころ、以下の本を買って勉強したことがあります。

    失敗のないシステム開発入門

    著者の加藤さんにはコンサルに来て頂いて、直にDB設計のノウハウを教授いただいたものです。

    当時はこの本の影響を受けて正規化に拘りまくり、テーブルを全て第五正規化までしておりました。
    おかげで確かに仕様変更には強いDB 構造になったのですが、いまとなっては正規化をし過ぎたため

    1.更新が面倒である。
    2.結合が複雑になりすぎる。

    嫌いがあることは否めません。やはり必要に応じて正規化崩しも必要でした。

    またオブジェクト指向に関しては

    「データにメソッドを持たせたものがオブジェクト」

    と言い切られておりますが、今となっては残念ながらその考え方は通用しないですね。(^ω^;

    ただこの頃より ER 図を作成する必要性を強烈に感じたので
    会社が買ってくれないため自腹で Visio を購入し、
    DB 設計の際は必ず Visio を使って ER 図を起こすようになりました。

    #ERWin は個人じゃ高すぎて手が出ない・・・(-ω-;

    業務別データベース設計のためのデータモデリング入門

    この本もかなりお世話になった本の一つです。

    テーブル設計のコツというか、かなり DB 設計の落とし所についてノウハウを明かしています。
    難点は独自の ER 図を使っているところ。普通の ER図に慣れていると
    渡辺式 ER 図は理解しにくいのですが、慣れてくると意図が明確に読めるようになります。
    でも後半は amazon のレビューどおり確かに読みにくいかも。

    実践的データモデリング入門

    この本はまだ読んでませんが、レビューを見る限りなかなか面白そうです。

    昔はデータモデリングに関する書籍ってホント少なかったのですが、
    DB Magazine がこの手の本を出すようになってから、かなりデータモデリングに関する書籍が増えてきたようですね。
    amazon のレビューを頼りに2~3冊購入して読み比べてみるのもいいかも知れません。
    • 回答としてマーク CrimsonPork 2009年11月25日 11:39
    2009年11月25日 6:20
  • ひらぽんさん、非常に親切な回答ありがとうございます。
    少し悩んだのですが、本気で取り組む気概もあるので、3冊とも早速購入しました。
    データモデリングっていうんですね・・・。そんなキーワードさえ知らなかった次第です。本と頂いたコメントを参考に取り組んでいきたいと思います。
    2009年11月25日 11:39
  • 私の想像だと、単純にそのレコードがいつINSERTされたのか、だれによってなのか、場合によってはいつ更新されたか、もしくは更新されていなければ、誰も更新していないということを保証するために
    あるのかといったところで止まってしまうのですが、これ以外にも用途などはあるのでしょうか?
    基本的にはCrimsonPorkさんの想像通りです。しかし、最後の「誰も更新していないということを保証するため」が同時実行制御の意味でしたら誤っています。理論的に同時の日時を取り得るからです。もっともdatetime2型を使うとほとんど可能性は無いと思いますが・・・。同時実行制御にはrowversion型を使用します。従来のtimestamp型はこれのシノニムになります。


    2.TBLやDB設計について現場で利用するようなテクニックが記載された本やリソースについて
    いまのところ、論理削除というやり方や1.の内容ぐらいしか知らないのですが、他にもこういうやり方があるので知っておくとよいというものがあれば、ぜひ教えていただきたいと思います。
    また、そういったものがまとまった本、DB・TBL設計において一度は読んでおくといい本やリソースなどがあれば知りたいです。
    少しご質問の内容から離れてしまう返信かもしれません。

    削除フラグや更新日時などはモデリングにおける流れの中で必要であるから出てきたものであり、特別なテクニックというわけではないと思います。肝心なことは如何にモデリングするかです。モデリングの具現化に際しては、サロゲートキーを使ったり、データの横持ち縦持ちを検討したり、速度やSQL文の制約などにより、実践的に考慮することが発生します。この辺りはそういう意味でテクニックと言えるかもしれません。
    ★良い回答には回答済みマークを付けよう! わんくま同盟 MVP - Visual C# http://blogs.wankuma.com/trapemiya/
    2009年11月25日 15:08
  • ひらぽんさん、非常に親切な回答ありがとうございます。
    少し悩んだのですが、本気で取り組む気概もあるので、3冊とも早速購入しました。
    データモデリングっていうんですね・・・。そんなキーワードさえ知らなかった次第です。本と頂いたコメントを参考に取り組んでいきたいと思います。

    ありゃりゃ!後の二冊はいいとして、最初の本はかなり古い本なので、ちょっと申し訳ない気が (汗

    最初の 失敗のないシステム開発入門 は DATARUN という方法論を使ってますが、
    いまとなってはある意味廃れてしまった方法論ですので、正直もったいないという感じです。
    ただし他の二冊と比較して、反面教師として捉えるのはいいかも知れません。

    DATARUN を勉強していた当時は

     「最初に完璧な設計をしておけば、システムは成功する」

    という考えでしたが、様々な現場を渡り歩いては色々な事例を目にし
    さらに DB設計ではないですが、 リファクタリング を読んでから全く考えが変わり、今では

     「完璧な設計などあり得ない。仕様落ちや仕様変更が発生したとき、如何に柔軟に対処するか」

    をテーマに開発に取り組んでます。

    おかげで今の現場では、一つの画面にコントロールが200個近く貼りつき、
    状況に応じてレイアウトがコロコロ変わる仕様というバケモノみたいなインターフェイスに加え
    まるでアジャイルのように週に2~3個は仕様変更が発生してますが、
    大した残業もせずにかなり余裕でこなし切れてます。

    私の経験から言うなら

    ・ テーブル設計は最初から完璧なものを求めない。仕変を考慮し、ある程度遊びを持たせた設計にする。
    ・ 実装に入った後で、テーブル構造の改変に繋がるような仕様落ちが見つかった場合、勇気を持って設計変更をためらわず行う。
    ・ 仲介者の情報を鵜呑みにせず、極力現場に潜って業務内容を掴むよう心がける。

    この三つはとりわけ大事だと思ってます。


    2009年11月25日 16:14