　アプリケーションで利用するデータの洗い出しが終わったら、これらのデータをどのように格納していくか、スキーマを設計していきます。前回説明したように、リレーショナルデータベースには行番号がありません。そのため、各表には各行を一意に判別できるキーが必要となります。このキーは表同士の連携にも利用します。例えば、施設情報を格納する次のような表を作成したとしたら、この表に操作を加えるといくつかの問題が発生するおそれがあります。


	施設名称	住所	施設分類
	東京タワー	東京都港区	観光地
	代々木公園	東京都渋谷区	電車
	代々木公園	東京都渋谷区	バス
	渋谷区役所	東京都渋谷区	バス
図2　問題のある表

　この表では、1つ目の“代々木公園”のデータを“代々木公園駅”に変更しようとしたとき、2つ目のバス停のデータを更新してしまう可能性があります。また、削除したとき、1つが残ってしまう可能性があります。これらの問題を解決するためには、施設番号という項目を追加し、この施設番号をユニークに振ることによって、この問題を解決します。


	施設番号	施設名称	住所	施設分類
	0001	東京タワー	東京都港区	観光地
	0002	代々木公園	東京都渋谷区	電車
	0003	代々木公園	東京都渋谷区	バス
	0004	渋谷区役所	東京都渋谷区	バス
図3　施設番号を追加した表

　これですべての問題が解決されたように思いますが、現在の状態では施設分類を更新するときに同様な問題が発生します。施設分類を施設情報の表に直接入れるのではなく、施設分類の表を作成し、施設情報の表にて施設分類番号を入力するようにします。実際に、施設情報のデータを参照するときは、施設情報の表と施設分類の表を連携して表示することになります。

図4　施設情報表と施設分類表との連携

　これ以外にも今回のスキーマ設計では、施設情報の表に都道府県の項目も入れる必要があり、都道府県の項目も都道府県名を直接入れるのではなく、都道府県番号を入力し、連携するようにする必要があります。

　また、ユーザーの訪問情報の表に格納される施設情報も施設名称を直接入れるのではなく、施設番号を格納すればいいことになります。

スキーマを作成しよう

　スキーマ設計を行い、スキーマの正規化が終了したら、設計したスキーマを作成します。スキーマの作成はSQL文にて行います。スキーマ作成で利用されるSQL文は以下のデータ定義言語（DDL）となります。例えば、表1のように設計した施設情報表を作成するSQL文はリスト1のようになります（このSQL文は日立製作所のEntierを例に作成）。

データ定義言語（DDL: Data Definition Language）

CREATE文：データベースオブジェクト（表、インデックス、制約など）の定義
ALTER文：データベースオブジェクトの定義変更
DROP文：データベースオブジェクトの削除

表1　施設情報表の項目

        CREATE TABLE LOCATION_INFO
        (
                LOCATION_CODE CHAR(5) NOT NULL,
                LOCATION_NAME VARCHAR(50) NOT NULL,
                PREF_CODE CHAR(3) NOT NULL,
                LOCATION_ADDRESS VARCHAR(200),
                LOCATION_TEL CHAR(12),
                LOCATION_CATEGORY_CODE CHAR(3),
                LOCATION_GPS GEOMPOINT 
        );

リスト1.施設情報表を作成するSQL文

　すべてのスキーマを作成するSQL文を実行したら、作成した表にテスト用のデータを登録し、正規化が問題ないことをテストします。また、アプリケーションの要件を元にインデックスの設計を行っていきます。

　インデックスの設計では、以下の点に考慮して行います。