スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

テーブルの実装

 いよいよ実際にテーブルを作成する段階になりました。ここまで来るのに大分時間をかけましたが、データベースシステムの構築においては、実際にプログラムを作る前にいわゆる設計作業をどれだけしっかりやるかがその後の工程に大きく影響します。先を焦って設計作業をおろそかにしてはいいシステムは作れません。

 もっともACCESSでのシステム作成においてはプログラム開発が進んでからの設計変更も比較的容易(他への影響範囲を最小限にして)に出来るようになっています。

 まずテーブルを作るためには新規でデータベースを作ります。データベース名は「生徒名簿」としておきます。尚今後、実際の基本的な操作方法に関しては、このブログでは特に必要がない限り解説しませんので他の解説本等を参照して下さい。

 テーブル名に関しては「T_生徒名簿」「T_家族」とします。「T_」を付加したのはそのオブジェクトがテーブルであることを明示するためです。今後クエリーやフォームが増えていった場合、名称のみを見てそのオブジェクトが何であるかわかるようにするためです。逆に言えばオブジェクトが違えば同名が許されるという事でもあります。例えばクエリーを作る時に元になるものはテーブルでもクエリーでも可能です。クエリーデザイナーを見ただけでそのオブジェクトが何であるかわかった方が便利です。

 では実際にテーブル仕様に基づいて作成したテーブルを以下に示します。

生徒番号テーブル
生徒名簿テーブル 

家族テーブル
家族テーブル 

 フィールド名ですが、ACCESSでは日本語名は自由に使えます。他のデータベースですと半角英数字しか使えない等制限があったりしますが、わかりやすさという観点から日本語名が使えるというのは便利です。

 学年に関してですが、これだけ数値型にしてあります。数値型は更に「バイト型」「整数型」「長整数型」等があります。各々の型によって記憶領域のサイズと実際の値の取り得る範囲が変わります。詳しくは以下のヘルプを見て頂きたいのですが、つまりは実際に発生するであろうデータを予め想定して型を決めておく必要があるという事です。少なくとも学年に関してはバイト型で十分です。

家族テーブルの学年
家族テーブルの学年 
データ型の概要
データ型の概要  

 テーブルに関してはまあこの位にして次に進みましょう。次回ではフォームに関してです。
スポンサーサイト

テーマ : データベース
ジャンル : コンピュータ

属性の決定(その2)

 属性の決定の続きです。前回示した生徒名簿テーブルと家族テーブルの表について詳しい解説をします。

 まず生徒名簿テーブルから。生徒番号はコードとしての意味を持ちますから、テキスト型にします。コードの場合、コード体系というのを決めておく事があります。つまり番号をどういうルールで付番するするかという事です。単純に古い順に1から順番に振っていくという方法もありますが、コードを見てある程度の意味付けが出来ると便利な場合が多いので、ここでは最初の4桁を入学年度の西暦の年、残り3桁を連番にしてみました。

 姓漢字、姓かな、名漢字、名かなは共にテキスト50桁にしましたが、何桁にするかはあまり厳密に考えなくてもいいでしょう。実際のデータが既にあって最大の長さがわかっている場合は、プラス10桁位にしておけばいいでしょう。むやみに桁を取りすぎると容量の無駄遣いになるし、少なければデータが入り切らなくなる可能性がありますので、長さを決めるのは実は結構難しいのです。

 ここでACCESSのうれしい特徴があります。他のデータベースだと設計時にフィールドの型や長さを決めたあと、データが蓄積されていった場合、後でデザインを変更するのは非常にやっかいになります。データを退避して、デザインを変更し、元に戻す(場合によっては変換する)必要があります。

 これがACCESSだとデータを入れたまま、テーブルのデザインを変更することが出来るのです。つまり、型や長さを自由に変えることが出来るのです。ただ注意しないといけないのは長さを長くする分には問題ないのですが、短くするときにはデータが途中で切れてしまう可能性がありますので、最大長のデータを確認してから行う必要があります。型を変更する場合も数値からテキスト型にする場合は問題ありませんが、テキスト型から数値型にする場合は当然の事ながら数値以外が入っていないことを確認する必要があります。もし、数字以外のデータが入っていた場合は変換エラーが起き、そのデータは失われてしまいます。

 性別は男と女しかありませんからテキスト2桁で問題ないです。

 生年月日、入学年月日、卒業年月日は日付時刻型です。もちろん時刻は入力しませんが。

 学年は数値型ですが、実際にはもっと細かい設定が必要です。それはACCESSでテーブル定義をするときに考慮しましょう。

 クラスは例えば1組、2組、あるいはA組、B組、あるいはさくら組、花組等いろいろ考えられるので、テキスト10桁にしました。

 郵便番号はハイフン付きの8桁。

 住所の都道府県からビル名まではテキスト100桁にしました。実際にはもっと少なくても大丈夫かもしれませんが、余裕を取っておきます。都道府県に関してはマスタを持ってコードで管理する方法もありますが、ここでは都道府県名そのものを格納することにします。

 TEL、FAX、携帯電話はハイフン付きでテキスト20桁にしました。これも余裕を取っています。ハイフン無しにした場合、入力は楽なのですが、表示したときに見にくいかと思います。自動でハイフンを付けるには区切りを判断するのは難しいと判断しました。

 メールアドレスに関しても余裕を持ってテキスト50桁にしました。

 次に家族テーブルに行きます。生徒番号は生徒名簿テーブルの連結フィールドなので、当然生徒名簿テーブルと同じです。
 家族番号は生徒名簿テーブルと関連性を持たせた方がいいと判断し、生徒番号(7桁)+連番2桁にしました。

 名漢字、名かなは生徒名簿テーブルと同じテキスト50桁にします。

 続柄はテキスト10桁もあれば充分でしょう。この続柄もコード化する方法もある事は前にも述べたとおりです。

 連絡先はTEL、携帯電話、メールアドレス、住所等汎用的に使うフィールドなので、テキスト100桁にしておきます。

 以上一通り、テーブルを設計しましたので、次は実際にACCESSのテーブルを作成していくことにします。

テーマ : データベース
ジャンル : コンピュータ

属性の決定(その1)

 いよいよテーブル設計も最終段階に来ました。洗い出した項目に対する属性を決定していきます。

 属性を決めるとは、各項目の型と長さを決めることです。更に言えばNULLを許可するか、規定値はどうするか、制約・ルール・参照整合性等細かく言えばいろいろありますが、ここでは最低限型と長さを決めます。

 データベース管理者という職種があり(アプリケーション開発者に対応すると考えて下さい)、データベースを外的から堅牢に守るという事を絶対視します。外的とはたとえ同じチーム内で作成したプログラムからであってもです。つまり、作成されたプログラムを信じていないところがあり、データベースの整合性を自己完結的に固持しようとします。

 得てしてアプリケーション開発者から見れば融通が利かないことが多く、両者の間に確執や軋轢を生むケースがあります。他システムと連携する必要があったり、過去のデータをコンバートする時など、あまりにガチガチに制約やルールを決められていて開発が立ちゆかない事があります。やはりバランス感覚が必要です。項目のチェックなどもテーブル定義上エラーにする事は出来るのですが、実務上は使い勝手が悪いケースが多いというのが私の経験です。画面側でチェックする方が、確実であり、応用が利き、変化に対応できると考えます。

 さて、項目の型にはどんな種類があるでしょうか。細かく言うとデータベースの種類によっていろいろあるのですが、わかりやすく大雑把に言うと「テキスト型」「数値型」「日付時刻型」です。最低限この型の種類を覚えておけば大概のシステムは何とかなります。後は必要に応じて型の種類を覚えていくことにしましょう。更に各々の型に応じて長さなどを決めていく必要があります。

 簡単に各々の型の特徴、どういう時にその型を適用するかという事をまとめてみます。(あくまでACCESSでのデータ型という前提です)

テキスト型:いわゆる文字を格納する為の型です。半角英数字・記号・ひらがな・漢字等を格納でき、最も汎用的に使える型です。テキスト型には長さを必ず指定する必要があります。ACCESSの場合は255バイトまでという制限があります。それより長い文字を格納するためにはメモ型を使います。ちなみに1バイトは半角文字1文字分、全角文字1文字には2バイト必要になります。

数値型:数値として操作する値を入れます。数字はテキスト型にも入れられますが、違いは数字を数値として扱うか文字として扱うかです。例えば「1」と「001」はテキスト型だと違う値になりますが、数値型だと同じと判断します。金額などは数値型にしますし、ゼロ自体も意味を持つコード類であればテキスト型にします。数値型には更に種類があるのですが、それは後述します。

日付時刻型日付と時刻を管理する項目です。もちろん日付だけでも大丈夫です。日付型にしておけば日付に関する入力形式、出力書式、チェック、計算等全てACCESSの機能で実現出来ますので非常に便利です。日付を例えば8桁の数字として数値型やテキスト型に格納することも可能ですが、日付としての操作は全部自前でやらなければならなくなります。

 以上のことを踏まえて、生徒名簿テーブル、家族テーブルの型、長さを表にしてみました。この詳しい解説は次回にて。
生徒名簿テーブルと家族テーブルの型

テーマ : データベース
ジャンル : コンピュータ

コード化、マスタ化

 今回はコード化、マスタ化について考えてみたいと思います。

 前回までに作成した生徒名簿テーブル、家族テーブルで既にコード化されているものがあります。それは「生徒番号」と「家族番号」です。コードとはそれ単体で意味を持つものではなく、他の項目やテーブルとの関連において役割を果たすものと考えてもらえばいいと思います。

 TELやメールアドレスもコードの一つと考えられなくもないですが(現実にはTELを顧客テーブルの主キーにしている例もあります)、その値内容自体に意味があり、単独で存在理由があるので、ここで言うコード化とはちょっと意味が違います。
 コードとは本来無ければないでも済む場合も多く(事実EXCELなので名簿を管理するだけなら、必要ないかもしれません)、データベースシステムとして厳密にデータを管理する上で必要となってくるものです。

 実は他に既にコードとしての意味をもっている項目があります。それは「郵便番号」です。郵便番号とはそれに対応する住所があってこそ意味をもつものです。ACCESSには郵便番号辞書テーブルというのが内蔵されていて、郵便番号を入力すると、それをキーに辞書テーブルが索引され、住所を引っ張ってくるようになっているのです。郵便番号辞書テーブルのように名称等、コードが持つ固定の情報を管理するテーブルをマスタといいます。その意味で言えば、生徒名簿自体も生徒の固有情報を管理しているわけでマスタといえます。マスタに対応する用語としてはトランザクション(テーブル)というものがあります。生徒名簿に起因するトランザクションとしては例えば成績テーブルなどです。

 トランザクションの例をもっと揚げますと、顧客マスタに対する受注データ。会計の世界で言えば勘定科目マスタに対する仕訳データ。Webのアクセスログもトランザクションデータです。つまり、日々刻々流動する取引や情報の流れを記録したデータという事になりますか。(そういう意味では何らかの日付は必須項目になります)

 コード化(マスタ化)する目的の一つにはデータ量の節約があります。郵便番号が必ず入力されると仮定すれば、都道府県・市区郡までは生徒名簿テーブルに保持しなくとも、本来は良いことになります。必要な時に郵便辞書マスタから取り出せば良いわけです。又、もう一つの目的としてはマスタの内容が変更されても整合性を保てるというのがあります。つまり、市区郡名が変わることになってもマスタの方を修正すれば、生徒名簿自体のデータは変更する必要はありません。
 ただ一般的には郵便番号と住所フィールドは両方持ちます。郵便番号が入力されないケースもあり得るし、辞書テーブルが保有している住所と実際の住所の表記が微妙に違う事も想定できるからです。

 つまりマスタが持っている情報をコードを持っている側のテーブルでも保有した方がいいかどうかはケースバイケースになります。例えば商品コードと商品マスタで例えれば、通常商品名や商品の価格は商品マスタで持ちますが、価格が頻繁に変わるようなケースですと、受注データに単価にもっていなかった場合(その都度商品マスタから索引する)、価格を変更すると過去の取引データの価格まで変わってしまいます。やはりその時々の単価を記録しなければなりませんので、通常は受注データにも価格をもちます(商品名はマスタ持ちで構わないと思いますが)。

 生徒名簿テーブルと家族テーブルで他にコード化出来るものがあるかどうかですが、厳密に言えば、性別・クラス・続柄等があります。つまり、性別であれば「男」「女」と値そのものをデータとして持つのではなく、コードとして「1」「2」ともつわけです。そして名称を管理するマスタを別に作り、そのマスタに「男」「女」を保有します。ただ、この場合に関して言えばそこまでするメリットはあまり感じません。データ量的にも大した違いはないし、性別の種類が今後増えるわけでもなく、呼び名が頻繁に変わるわけでもないからです。

 よってコードとしてはこれ以上追加しないことにします。念の為、他に追加する項目がないか確認しておきます。生徒が入学した日と卒業した日を記録しておいた方がいいと思われるので、「入学年月日」と「卒業年月日」を追加しておきます。

 最新の生徒名簿のマインドマップを掲示しておきます。
生徒名簿テーブル 家族テーブル
 次回では洗い出した項目の属性の決定について考察していきます。

テーマ : データベース
ジャンル : コンピュータ

リレーショナルテーブルの検討

 家族フィールドですが、家族の構成員が複数いた場合はどう表現するでしょう。仮に同じ生徒名簿テーブル上に家族1、家族2、家族3と定義していった場合、人数がわかっていないのでフィールドをいくつまで用意しておいていいかわかりません。例えば10人位で用意しておいた場合にそれより超えた場合に対応できないし、それより人数が少ない場合余った領域は無駄になります。

 このように1:Nの関係にある情報を関連づけるのにリレーショナルテーブルというものを考えます。もちろん結果的に1:1に終わったとしても問題ありません。場合によっては1:0であってもシステム上は問題ありません。もっともこの場合家族の全くいない生徒というのは考えづらいですが。

 家族テーブルとしてテーブルを分けた場合、次に考えなければならないのは生徒名簿テーブルと家族テーブルを結びつけるにはどうするかという事です。この場合、家族テーブルに生徒番号を持たせます。この生徒名簿テーブルと家族テーブルを関連づける生徒番号の事を連結キー又はリレーショナルキーと言ったりします。

 実は家族テーブルで必要になってくるものがあるのですが、おわかりでしょうか。そうです。主キーです。家族一人一人をユニークにするための番号です。ここではそれを家族番号と名付けましょう。


 以下に修正した生徒名簿のマインドマップを示します。
生徒名簿テーブル 家族テーブル
 ここでキーについてまとめておきます。

 主キー:そのデータをユニークにする値を持つフィールド。生徒名簿テーブルでは生徒番号、家族テーブルでは家族番号になります。実際には主キーを設定していなくとも問題のないケースもありますが、パフォーマンス、他データベースの互換等、後々考えると主キーのないテーブルは問題を孕んでくるケースがありますので、主キーはどの場合も設定した方が望ましいと思います。

 連結キー:リレーショナルテーブル同士の関連づけをする為のフィールド。片方のテーブルにとっては主キーが連結キーになります。この場合生徒番号ですが、これは生徒名簿テーブルの主キーにもなっています。つまり、生徒番号一つに対し、同一生徒番号をもつ家族番号は複数あり得ると言うことです。

 副キー(インデックス):これは必ずしも必須ではないですが、目的は検索速度を上げるために設定します。主キーをインデックスにする場合ももちろんあります。例えばTELで検索する頻度が多いと仮定するならこれをインデックスにします。データ件数が多くなればなるほどインデックスの効果は絶大となります。ただデメリットとしてはあまりインデックスを張りすぎると更新速度が遅くなります。インデックスについては設計時ではなく、運用後に追加・削除が自由に出来るので、検索の傾向がはっきりしてから設定してもOKです。ここではまだ副キーは付けないでおきましょう。

 さて次回ではコード化、マスタ化について考えてみることにします。

テーマ : データベース
ジャンル : コンピュータ

最新記事
全記事表示リンク

全ての記事を表示する

月別アーカイブ
カテゴリ
お問い合わせ
まずはこちらのフォームより御一報下さい。

名前:
メール:
件名:
本文:

検索フォーム
RSSリンクの表示
アクセスランキング
[ジャンルランキング]
コンピュータ
859位
アクセスランキングを見る>>

[サブジャンルランキング]
ソフトウェア
108位
アクセスランキングを見る>>
ブログランキング

FC2Blog Ranking

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。