Access データ型の決定 講座 Vol.2

さてデータベースの正規化も完了し、次はデータ型とフィールドを構築します。データ型を適切に決定しないと、運用し始めてからでは基本的に変更はできません。

どの＜フィールドの項目＞には、どの＜データ型が適切なのか＞を学びましょう！

関連講座

1. Access データベースの正規化 講座 Vol.1
2. Access データ型の決定とフィールドの構築 講座 Vol.2　←　ココ
3. Access ルックアップウィザード 講座 Vol.3
4. Access リレーションシップ 講座 Vol.4
5. Access クエリ作成 講座 Vol.5
6. Access 関数の使い方 講座 Vol.6

フィールドを構築する時の注意点

 

主キーのデータ型は何にする？？

主キーの代表的なデータ型には＜オートナンバー型＞、＜数値型＞、＜テキスト型＞の３つがあります。さて、この中で一体どのデータ型が適切なんでしょうか・・・？？

それぞれのデータ型のメリットとデメリットを確認してみましょう。

※論理設計の方向性や業務形態によっても、データ型の決定は変わってきます。あくまでも、ご参考までに。

 

【オートナンバー】の特徴

オートナンバーは自動採番してくれるため非常に便利ですが、一方で汎用性に欠ける場合もあります。「便利だから、主キーはオートナンバーでしょ！」と安易に設定すべきではありません。

メリット

1. オートナンバーは自動的に入力されるので、データ入力が楽になる。
2. データが昇順、降順に整列できる。

デメリット

1. 汎用性に欠け、やりたいことが制限される可能性がある。
2. レコードを削除すると欠番が発生する場合がある。

 

【数値型】の特徴

数値型には以下のような特徴があります。

メリット

1. ルックアップウィザードが容易に利用できる。
2. データが昇順、降順に整列できる。

デメリット

1. 自動的にインクリメント（自動採番）されない。
2. インクリメントするためには、入力フォームなどのコントロールにマクロや関数を設定しなければならない。

 

【テキスト型】の特徴

テキスト型には以下のような特徴があります。

メリット

書式を使用せずに文字列を設定できる。

デメリット

1. 自動的にインクリメント（自動採番）されない。
2. インクリメントするためには、入力フォームなどのコントロールにマクロや関数を設定しなければならない。
3. データが昇順、降順に整列できない。（※１）

※１.データ変換関数を利用すれば整列できます。

 

さて、今まで＜オートナンバー＞＜数値型＞＜テキスト型＞のメリット・デメリットを記述してきました。業務形態や論理設計の方向性によってデータ型は何が適切なのかはケースバイケースでしょう。しかし、私なら一番汎用性の高い＜数値型＞をお勧めします。

＜数値型＞のデメリットは自動的に採番されないことですが、そこは関数・マクロで補います。さらに、＜注文ID＞や＜顧客ID＞はかなりレコードが増えることを考慮して、＜長整数＞に設定しておきます。「CS0000-00001」などの書式は、入力フォームで設定します。

それは、後々に詳細に説明しますが、この時点で書式を設定すると、ルックアップウィーザードが制限されるためです。

 

データ型の想定

T_注文テーブル

フィールド名	データ型	必須の有無	説明
注文ID	数値型（長整数）	○	例：Ｈ00000-00000（H + 5桁 + 5桁）
注文日	日付/時刻型	○	例：2015 / 07 / 15
顧客ID	数値型（長整数）	○	例：CS00000-00000（CS + 5桁 + 5桁）

顧客からの注文データを格納するためのトランザクションテーブルです。「いつ」「誰が」の情報がこのテーブルから分かります。

主キーは＜注文ID＞に設定します。

書式はフィールド構築時には設定せず、入力フォーム作成時にコントロールに対して設定していきます。ここでは、説明の欄に下記のような例を記載して、あとあと役立てるようにしておきます。

 

T_注文詳細

フィールド名	データ型	必須の有無	説明
注文ID	数値型（長整数）	○	例：Ｈ00000-00000（H + 5桁 + 5桁）
商品ID	数値型（長整数）	○	例：SN00000（SN + 5桁 ）
個数	数値型（整数）

顧客からの詳細な注文データを格納するためのトランザクションテーブルです。T_注文のテーブルと合わせることで「いつ」「誰が」「何の商品を」「いくつ」購入したのか？が分かります。

＜注文ID＞のみを主キーに設定してしまうと、重複してしまいます。

なので、この注文詳細では、主キーは＜注文ID＞と＜商品ID＞の複合キーに設定しています。

 

M_顧客

フィールド名	データ型	必須の有無	説明
顧客ID	数値型（長整数）	○	例：CS00000-00000（CS + 5桁 + 5桁）
顧客名	テキスト型	○	フリガナ入力
フリガナ	テキスト型
郵便番号	テキスト型	○	住所入力支援
都道府県	テキスト型	○
住所１	テキスト型	○
住所２	テキスト型		建物名・部屋番号など
メールアドレス	テキスト型
電話番号	テキスト型	○

顧客情報のデータを格納するためのマスタテーブルです。

主キーは＜顧客ID＞に設定します。

 

M_商品

フィールド名	データ型	必須の有無	説明
商品ID	数値型（長整数）	○	例：SN00000（SN + 5桁 ）
商品名	テキスト型	○
単価	通貨型	○
区分コード	数値型（長整数）	○	例：KB000（KB + 3桁 ）

商品情報のデータを格納するためのマスタテーブルです。

主キーは＜商品ID＞に設定します。

＜区分コード＞は外部キーです。

 

M_商品区分

フィールド名	データ型	必須の有無	説明
区分コード	数値型（長整数）	○	例：T000（T + 3桁）
区分名	テキスト型	○

商品区分のデータを格納するためのマスタテーブルです。

主キーは＜区分コード＞に設定します。

区分コードの説明にもありますが、区分の種類は多くないので、桁数は3桁にしてあります。

 

いよいよフィールドを構築してみる

フィールドを構築するときに必要になるのが、プロパティの設定です。＜フィールドのサイズ＞＜値要求＞＜インデックスの設定＞＜定型入力＞＜住所入力支援＞などです。

 

フィールドのサイズの決定

フィールド名	データ型	フィールドのサイズ
顧客ID	数値型（長整数）	ー
顧客名	テキスト型	３０
フリガナ	テキスト型	３０
郵便番号	テキスト型	７
都道府県	テキスト型	１０
住所１	テキスト型	５０
住所２	テキスト型	５０
メールアドレス	テキスト型	５０
電話番号	テキスト型	１１

フィールドサイズはテキスト型だと初期値は＜255＞に設定されています。このフィールドサイズを適切なサイズに直します。

＜住所＞や＜メールアドレス＞は、長くなることもあので、余裕をもってサイズを決定しておきます。

 

フリガナ支援の適用

 

顧客名からフリガナフィールドへ、自動的にフリガナが入力されるようにフリガナ支援を設定します。今回は既存のフィールドへ自動入力をするので＜フリガナフィールド＞を設定します。

さらに、＜ひらがな＞＜全角カタカナ＞＜半角カタカナ＞の３種類のタイプから選択しましょう。

 

住所入力支援の適用

 

 

郵便番号から都道府県・住所へと自動的に入力されるように、住所入力支援を設定します。プロパティ欄の下部にある＜住所入力支援＞のボタンを押下します。今回は＜郵便番号＞　⇒　＜都道府県＞＜住所１＞の２つのフィールドへ自動的に入力します。

住所入力支援ウィザードで＜都道府県と住所の２分割＞を選択すればＯｋです。