- PR -

業務系のDBでは制約を持たない?

投稿者投稿内容
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-03-31 09:52
はにまるです。
まず、インギさんの「参照整合性制約とER図を別ける考え」に賛同して、

参照整合性制約について
  データの依存関係を人間の思考レベルで考えた場合、ON/OFFでは無く、

    1.常に必須(Error)
    2.特定条件により必須(if Error)
    3.出来れば合わせて欲しい(Warning)
    4.特定条件により出来れば合わせて欲しい(if Warning)
    5.あったらあったで良い

  という段階的な依存関係に別けれます。
  勿論、データを扱う立場によってこの要求は異なりますし、
  システムの組み方によって、1〜5の全てを使う訳ではありません。
  
  この事から参照整合性制約は、1に有効ですが、2〜5では有効では無い為、
  「依存関係はプログラムで全て処理する」考えに落ちついていると思います。

ER図について
  実は、DB構成を用いてオブジェクト指向設計のあり方考える事を
  「初心者が教える「オブジェクト指向で設計する技法」」で取上げ様と考えていました。

  まだ模索途中ですが、その途中経過の考えを絡めてお伝え致します。

  全DBを1つのER図で記述するのは困難ですし、
  システムの規模に反比例する形で、その困難さの度合いは高まります。

  そこでER図は、マスタ、基本業務フロー、集計情報(分析系目的)で
  別けた方がよいと思います。
  # 勿論、ここで言っている3つは簡易で言っているだけで、そのまま受売りするのでは無く、
  # 対象システムのDBを洗い出し、性質の似た物を見つけ考えていく事が必要です。

  また
  ER図は、「DBとその関係を矢印のみで記述する」という概念を捨てて、
  ER図は、「DB関連を示す事が目的である」という概念で、
  簡易な処理を記述した方が理解し易いのであれば明記する位の柔軟な思考が必要と思います。

  今回の話に意見させて頂くと、
  ER図を書く事の目的を考えず、メリット/デメリットも論じず、
  安易に作らないと言う方向に持っていく姿勢ならば疑問を感じます。

  ER図が無いと言うのは、非常に疑問に感じますし、外部者ながら賛成出来ません。
  その関係図を補う資料があれば別ですが...

以上が、はにまる的見解です。
Beatle
ぬし
会議室デビュー日: 2003/06/09
投稿数: 394
投稿日時: 2004-03-31 10:05
まぁDBなんて「生き物」と考えても良いくらい変わるものなので...ってそれじゃ
ダメなんでしょうけどね。

ただ、システムの規模にもよりますが、DBの設計は論理設計と物理設計に区別されます。
論理設計部分ではビジネスロジックや機能面からのテーブル設計等を行うので、
提示されているエクセルファイルというのがこれにあたると思います。
で、各テーブルをどのように読むかというのは複雑な場合にはわかりにくいので、単純
な項目間の関係はER図として書きますが、CallingSequenceとしてビジネスロジック
部分の設計書やDFD等の設計書または詳細設計書のようなところに記述したりします。
複雑な場合には新たにViewを定義したりもします。

ただ、ここはあくまでも論理設計レベルなので、実体のテーブルがどうなっているかは
物理設計段階で決まります。極端に言えばエクセルファイルで提示されたテーブルレイア
ウトはすべてViewなのかもしれません。ここはレスポンスや効率、バックアップ等を考
えて設計されます。この段階で参照整合性制約とかを物理的にどうするかというのが
吟味されることになるので、論理設計段階でのERは単に関連があるという形で表します
ね。

まぁ、これは比較的大規模な場合なので、余裕が無い場合には論理設計のテーブルがその
まま物理的に定義される事が多いですが...

※個人的には参照整合性制約というのはよほどのことが無い限り使いませんです。
七味唐辛子
ぬし
会議室デビュー日: 2001/12/25
投稿数: 660
投稿日時: 2004-03-31 10:21
論点がずれてきましたね ER 図を使うかどうかは論点ではないです。
もちろんあったほうがよいのが言うまでもないですが、

使いたくても使えない場合もあります。
ER 図をつかえばあるていど厳密にDB設計できますが、古から伝わるDBの場合
DB設計がRDB的な厳密さからほど遠い場合があります。
そのような場合ER 図では表現できません。


七味唐辛子
ぬし
会議室デビュー日: 2001/12/25
投稿数: 660
投稿日時: 2004-03-31 10:55
論点がずれてきましたね ER 図を使うかどうかは論点ではないです。
もちろんあったほうがよいのが言うまでもないですが、

使いたくても使えない場合もあります。

ER 図をつかえばあるていど厳密にDB設計できますが、古から伝わるDBの場合
DB設計がRDB的な厳密さからほど遠い場合があります。
そのような場合ER 図では表現できません。

>結論的に知りたいのは、ある業務ロジックを実装しようとする場合、どのテーブルとどのテー
>ブルをどんなふうにつなげばいいのかをどうやって分かりやすく表現できますか?

表現方法ですが、処理単位ごとにER図みたいのを書く
あるいは文字列ですね。


[ メッセージ編集済み 編集者: 七味唐辛子 編集日時 2004-03-31 11:19 ]
永井和彦
ぬし
会議室デビュー日: 2002/07/03
投稿数: 276
お住まい・勤務地: 東京都
投稿日時: 2004-03-31 10:57
個人的な経験では、開発段階ではDBの外部参照制約は明示的には付けない場合が多い(良い)ように感じています。
#で、結局そのまま付けないで終わる……

これを付けてしまうと、当然ですが「整合性を確保したデータ」が常に要求されてしまいますので、開発途中で「ダミーデータが欲しい」等となった場合にひどく面倒だったりするからです。
また、テーブルの変更等あった場合にも参照整合性制約がくっついていると、親テーブルの再構成(分割)を行いたいだけなのに子や孫に波及したりと、面倒に感じることも多いです。

で、明示的に参照整合性が定義されていない場合、システムとしては知ったことでは無い(検知する方法が無い)ので、ツールによるER図の自動生成が出来ません。ので、「忙しい」のを理由に後回しにされてしまうことも多々あるように思います。
#そして、質問を受ける度に毎回口頭(&手書き)で説明して、結局余計に時間を取られる

・外部参照を行うカラムのカラム名を工夫して、どれを(暗黙に)参照しているのか分かるようにする
・大雑把な関係図だけは書いておく(主要テーブル以外は書かない等)

という辺りが妥協点かなと思いますが……。

逆に大雑把な図を自分で(自分のために)作成して、毎回それを携えて質問等に行くようにするとかはどうでしょう。まあ、不必要なときまで毎回提示する必要はないですが。
「ああ、これが繋がってるのは、そっちじゃなくてこっち」
という感じでツッコんでもらえると思うので、それを受けて修正して行けば現状に対する理解も早まるのではないでしょうか。
#で、あれば便利(な場合も多い)なので、そのうち共有されると思います
##私は手書きか、エクセルで適当なリレー図を作ることが多いです

「正確なもの」「綺麗な(体裁の整った)もの」を求められるのは疲れますので、「ERっぽい図」くらいで妥協しておくのがオススメです。


[ メッセージ編集済み 編集者: 永井和彦 編集日時 2004-03-31 12:30 ]
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-03-31 11:37
引用:

七味唐辛子さんの書き込み (2004-03-31 10:21) より:
論点がずれてきましたね ER 図を使うかどうかは論点ではないです。
もちろんあったほうがよいのが言うまでもないですが、


  確かに、「他の人の意見」と「スレッド主の質問」とが混在していましたが、
  今回は、テーブル定義書しか無い、「そんなので設計出来るか!」という事と認識しました。

  そのような意味で考えると、関連を示す図が欲しい
  DBなので、DBの関連図→ER図の話に発展しても問題は無いと思います。

  ただ、「参照整合性制約」の話は飛びすぎかな?

# 編集-追記
  七味唐辛子さんで、追加投稿されているのを見落としていました。
  後タイトルから「参照整合性制約」の話になっても変では無いと思いました。
  失礼しました。
# 編集-追記

引用:

使いたくても使えない場合もあります。
ER 図をつかえばあるていど厳密にDB設計できますが、古から伝わるDBの場合
DB設計がRDB的な厳密さからほど遠い場合があります。
そのような場合ER 図では表現できません。


  ER図は厳密性(正確性)を求める物なのでしょうか?
  私は、解り易さを求めています。

# ↓編集-訂正 … 勘違いで第1投稿文書に対する返答をしてしまいました。

話をスレッド主の質問に戻し、
  変更が多いならば、逆に残す設計書は何かを考える必要があると思います。
  そうすれば、詳細設計より、理解の手助けとなるER図や概要設計の方が
  重要視されると考えています。

# ↑編集-訂正


[ メッセージ編集済み 編集者: はにまる 編集日時 2004-03-31 13:46 ]
未記入
大ベテラン
会議室デビュー日: 2003/11/24
投稿数: 121
投稿日時: 2004-03-31 12:26
ER図は非常に有用だが、外部参照制約は足かせになることも多い、
という意見がほとんどですね。私も同意見です。

世の中には、データベーススキーマから自動的に ER図を出力するツールがあります。
これらのツールで ER図を自動出力するためには外部参照制約が必須です。

ER図の自動作成のために、次プロジェクトから外部参照制約をちゃんと付けようと
思っていたんですが・・・。どうしようかな。。
みなさんは、どのように ER図を作成しているのでしょうか。

はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-03-31 12:47
昔一回だけ、参照整合性制約を使いました。
その結果、永井和彦の仰る、作業の柔軟性に欠けるとの事で、
「参照整合性制約を取払う処理」「参照整合性制約を取付ける処理」を
作ったのですが....

その後、「参照整合性制約」を付ける事は無くなり、
テスト時にデータ検証で、「参照整合性制約を一時的に取付ける」と言う。
なんか、目的が異なる物になり果てていました。
それは、それで、面白かったです。

>みなさんは、どのように ER図を作成しているのでしょうか。
後付けが殆どです。

スキルアップ/キャリアアップ(JOB@IT)