TOP＞設計・移行・活用＞ はじめに




実践！モデリングツール
即活用！ツールを活用したデータモデリング

第４回：制約の使い方、Unicode使用可否、明細テーブルの設計
 著者：システムインテグレータ  梅田 弘之   2006/4/7
1   2  3  次のページ
はじめに

   前回は、データベース設計で誰もがぶつかる問題である「列名に日本語を使うか?」「どのデータ型を使うか?」ということをテーマに取り上げました。今回も引き続き、データベース設計で迷いやす点をいくつか取り上げ、筆者の考え方を参考にしていただこうと思います。
RDBMSの制約とは

   前回、説明したデータベースの標準規格SQL99では「制約」という機能が定義されており、OracleやSQL Serverなどの通常のRDBMSにも実装されています。

   制約とはデータベースに格納されるデータに制約条件を付けるものです。例えば、NOT NULL制約が設定されている項目はNULLを許容しませんので、必ず値がセットされなければなりません。制約を設定した列に、値を指定せずにデータを格納しようとしても、RDBMSが制約違反ということでエラーを返します。

   RDBMSで実装している制約には、表1のようなものがあります。

制約 内容
主キー制約 テーブルに1つ設定するもので、そのキーを指定すればデータ（行）が特定できるもの。一意であることが保証されると同時に、インデックス情報も持つので検索が速くなる。
一意制約 一意を保証して、インデックス情報を持つのは主キー制約と同じ。主キー制約との違いは、テーブルに1つとは限らず複数設定できること。
NOT NULL 制約 NULL（値が入っていない状態）でないことを保証する制約。
チェック制約 任意の制約条件に違反した値が入らないことを保証する制約。例えば、in(1,2)という制約条件を設定すると、その列には1か2しか格納できなくなる。
参照整合性制約 他のテーブルとの整合性を確保するために制約。例えば、受注テーブルの顧客番号（外部キー）と顧客テーブルの顧客番号（主キー）に参照整合性制約を設定すると、顧客テーブルに存在しない顧客番号を受注テーブルにセットできなくなる。
デフォルト制約 項目の初期値をセットする機能で、厳密には制約的な機能ではないが便宜上制約として扱っている。例えば、数量という列に1というデフォルトを設定しておくと、値を指定しない場合に1がセットされる。

表1：RDBMSの制約

   これらの制約は、あるからといって必ず使うとは限りません。筆者は仕事柄、様々な会社のデータベースに触れる機会が多いのですが、主キー制約とNOT NULL制約くらいしか使っていないというシステムも非常に多くあります。
どの制約を使うか

   データベース設計を行う場合は、どの制約を使うかという方針を決めなければなりません。ただし、データ整合性チェックをすべて制約に頼ってはいけません。一般にRDBMSの制約を設定したとしても、あくまでも1次チェックはフロントアプリケーション側で行います。

   図1は、典型的なWebアプリケーションの3層構造を示したものです。

Webアプリケーションにおける3層チェック
図1：Webアプリケーションにおける3層チェック

   このようなアプリケーションにおいては、下記にあげる3重チェックが行われることになります。

   第1チェックは、クライアント上のJavaスクリプトなどによるチェックです。これは主にユーザビリティを高めるためのチェックであり、ユーザが誤った値を入力したときに即座に過ちを指摘してくれます。

   第2チェックは、サーバサイドのチェックです。このチェックが一切の不整合値入力を許さない砦となります。

   そして、念のためのチェック（第3チェック）がRDBMSの制約です。制約を設定しておけば、上記のような想定アプリケーションを通さずに直接データを入力するようなことがあっても、整合性を確保することができます。また第2のチェックに漏れがあったとしても、制約が張ってあれば最低限の整合性が保たれます。

   この「念のため」というだけの理由で制約を設定すべきかどうか、これが設計者にとって悩ましいところです。制約を設定するとテストデータ作成時に面倒になりますし、制約によってはパフォーマンス低下というデメリットもあるからです。

   筆者の基本方針は、「積極的に制約を設定してデータの整合性を確保する」というものです。ただし、参照整合性制約だけはパフォーマンスが低下するので設定しません。以前は、依存型リレーションのみ設定したのですが、それも中途半端なので最近は一切使わない方針にしました。
1   2  3  次のページ

システムインテグレータ 梅田 弘之
 著者プロフィール
株式会社システムインテグレータ  梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。 常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。 国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。


この記事の評価をお聞かせください
 ボタンをクリックしますとウインドウが開きます。
 ご意見、ご要望にお応えします！ インプレスIT INSIDE
INDEX
第4回：制約の使い方、Unicode使用可否、明細テーブルの設計
はじめに
  論理モデル上だけリレーションを引く
  明細テーブルの主キーの持ち方
即活用！ツールを活用したデータモデリング
第1回 ソフトウェア産業に産業革命を起こすデータモデリング
第2回 ERの基礎知識とツールの活用法
第3回 日本語名の是非とデータ型採用方針
第4回 制約の使い方、Unicode使用可否、明細テーブルの設計
第5回 教科書的ではなく、現場にあったデータベース設計のコツ
即活用！業務システムの開発ドキュメント標準化
第1回 開発ドキュメント体系と業務フロー
第2回 機能一覧表とI/O関連図
第3回 基本設計書
第4回 詳細設計書（前半）
第5回 詳細設計書（後半）
第6回 単体テスト仕様書＆報告書
第7回 結合テストと総合テスト
第8回 要求仕様書の標準化プロセス
「即活用！企業システムにおけるプロジェクト管理」
第1回 プロジェクト管理力を強化するための具体的プラン
第2回 PMBOKをベースにしたプロジェクト管理の管理
第3回 スコープ管理とスケジュール管理
第4回 コスト管理の構造と見積手法
第5回 品質管理
第6回 組織管理
第7回 コミュニケーション管理
第8回 リスク管理
第9回 調達管理（外注管理）

Think IT 過去人気記事

Think IT
注目おすすめ情報

Think IT人気ライター BEST 5

People
IT製品/サービス資料ダウンロード
    おすすめのホワイトペーパー情報を準備中です