- - PR -
業務系のDBでは制約を持たない？
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-03-31 12:55
NAL-6295です。
個人的な経験から言えば、外部参照制約は以下の点で有益だと思っています。 （DB設計時にちゃんと正規化されていて、システム側のDBアクセス部分もエンティティ層に隠蔽されているならという前提ですが。） ・ダミーデータの作成に気を使う必要があるが、作成範囲が絞られる。 ・エンティティ間の整合性についてシステム側で実装する必要が無くなる。 よって、その部分についての、作りこみによる不具合の発生がおきない。 （作りこまないから。） あと、DB設計変更による影響範囲も、外部参照制約のあるなしによる違いはそんなに無いかなと思ってます。 ちなみに、いろいろ面倒な事もあるけど、後に楽する布石になってると感じてます。 | ||||||||
|
投稿日時: 2004-03-31 13:09
suminさんがJavaで開発していらっしゃるということなので、Javaがらみで行くとER図そのものは作成していませんが、永続オブジェクトとしての関連を定義するクラス図で代用しています。作り方としては一つのテーブルに対して一つの永続化クラスを割当てそのメソッドとしてどのような検索を行うのかをAPI仕様としてJavaDocコメントに書き込んでいます。 5年ほど前まで私はとあるDBベンダーに勤務していたDB屋だったのですが、その頃からデータオリエンテッドな設計というものに疑問をもち始めていました。システムを利用するユーザにとってデータが実際にどのように格納されているかということは重要ではない。本当に重要なのはデータを検索・集計するということで、それが時代の変化とともに頻繁に変更されるからDBに対する自由度の制限をつけることは間違ってるんじゃないか？ 当時はやり始めていたデータウェアハウスという概念はまさにそれに当てはまるものでした。自分自身勝手に「クエリーオリエンテッドな設計」と呼んでいますが、システムとして必要なクエリーはどんなものなのかを考えることで、それらのクエリーを最適に処理できるテーブルの配置などはおのずと決まってくると思います。 ということで、自分勝手な「クエリーオリエンテッドな設計」では参照整合性は必要とされていませんからテーブル間の関連を表現するようなER図も作成していません。もっと極端な言い方をすればER図を見てもクエリーが思い浮かばないなら、私にとってはそんなER図は見る価値がないということになります。 | ||||||||
|
投稿日時: 2004-03-31 13:35
この場合の厳密性は項目名称をルールにしたがってつける 名称をちゃんと設定する 番号とか名称とかいう項目名は使わない よほどの事情がないかぎり 複合項目をやめる ＸＸ番号の最初の２桁がＸＸ区分で、次の４桁が●●区分とかそんなやつです ＥＲＤとは直接は関係ないですが、世の中には、適当としか思えないテーブル構造を 設計する人はいます。 | ||||||||
|
投稿日時: 2004-03-31 14:00
確かに．．おっしゃる通りです。 自分の環境状態を前提として話をしていました。 例を示して頂いたので理解出来ました、丁寧にありがとうございます。 昔担当していたシステムや、外部システムとして調査したシステムに 七味唐辛子さんが指摘する設計を、ちょくちょく見かけます．．．
投稿日時: 2004-03-31 11:37の変更返答分です。 あっちは、無視して下さい。 >結論的に知りたいのは、ある業務ロジックを実装しようとする場合、どのテーブルとどのテーブル >をどんなふうにつなげばいいのかをどうやって分かりやすく表現できますか？ 単純に トランザクションにマスタを引っ掛けて表示する話であったり、 伝票と明細を結合して表示する話のレベルであれば、 ＥＲ図で良いとは思いますが、 そのレベルの話では無い場合、 将来の業務要件に対し、要求を満たす為、既存の設計書で「こうつなげないさい」と 表記する事は難しいと思います。 （正確には、私は無理と考えています。） 皆様に解り易い例で行けば、（解り易いか？） 要求：システム開発プロジェクト単位の収支報告書が欲しい。 問題：プロジェクト単位の収支情報は管理していない。 現状：現在は所属組織単位の収支集計情報は管理してある。 手段：詳細レベルの収支情報を利用し「プロジェクト所属マスタ」より所属社員を 結合情報として取得し集計する。 作業に取り掛かると、 1.詳細レベルの収支情報は、社員のみで、派遣社員の経費は別システムに存在した。 2.詳細レベルの収支情報は、１日単位で一人が複数Ｐｒｊに参画している場合、 計算出来ない（要求される管理単位で無かった） 3.要求とは、データの発生タイミングが違った。 こなると、 せいぜい、「テーブル設計書」に「プログラム設計書」並の情報を記載する事位しか思いつきません。 １．テーブル単位で、目的、（発生／消滅／変更）の補足事項、 管理期間、レコードの管理単位を記述 ２．項目単位で、目的、（発生／消滅／変更）の補足事項を記述 この際、記述するのは業務レベルです。例えば、 ×：作業情報は、作業日報入力／作業一括登録で更新されてたら発生。 〇：作業情報は、実作業をした時点有効とする。 但し、長期出張などで先行登録は可能とする為、 先行登録分は「予定項目」が「確認」済で無いと無効。 また、大阪支店からの情報は１日遅れで本部に到着する。 という風に将来の設計者に情報を提供する感じで．．． # 編集 ２つ例題が別々の業務の話だったので、後の例題を修正 [ メッセージ編集済み 編集者: はにまる 編集日時 2004-03-31 14:25 ] | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。