この特集のトップページへ
Chapter 6:ビジネスロジックの設計



  COLUMN    お詫び:「Chapter 3 データストア層の構築」の修正

 初掲時の履歴テーブル(Table 3-20)に誤りが発見されたので,ここで訂正させていただく(掲載中のTable 3-20は,すでに修正させていただいた)。初掲時のTable 3-20では,どのレコードが修正されたかを特定することができない。そこで次のように,Table 3-20RECORDIDという新しいフィールドを付け加える。RECORDIDフィールドには,変更の対象となったレコードのレコードID(主キー)を記録する。それにより,どのレコードが変更の対象となったのかを記録できるようになる。

Table 3-20(正) 履歴テーブル
フィールド名 サイズ NULL 解説
ID 数値型 (オートナンバー) 不可 レコードに対して唯一無二の値を割り当てる
DATE 日付型 不可 変更が生じた日時
TABLENAME 文字型 32 不可 変更が生じたデータベーステーブル名
FIELDNAME文字型32不可変更が生じたデータベーステーブルのフィールド名
RECORDID数値型不可変更が生じたレコードのレコードID(そのデータベーステーブルにおいて主キーとなっているフィールドの値)
OLDDATA 文字型 256 更新まえのデータ
NEWDATA文字型256更新後のデータ
UPDATEUSER文字型256不可更新したユーザーのアカウント名
 この変更に伴い,Fig.3-19Table 3-30Fig.3-23Fig.3-48も,下記のように修正させていただく。また,修正したデータベースを作成するためのSQL文は,次のとおりである(「3.5 まとめ」を参照)。
Fig.3-19(正) 履歴テーブルに履歴を残す
fig3_19.gif

Table 3-30(正) 履歴テーブル
フィールド名 サイズ NULL 解説
ID 数値型 (オートナンバー) 不可 レコードに対して唯一無二の値を割り当てる
DATE 日付型 不可 変更が生じた日時
TABLENAME 文字型 32 不可 変更が生じたデータベーステーブル名
FIELDNAME文字型32不可変更が生じたデータベーステーブルのフィールド名
RECORDID数値型不可変更が生じたレコードのレコードID(そのデータベーステーブルにおいて主キーとなっているフィールドの値)
OLDDATA 文字型 256 更新まえのデータ
NEWDATA文字型256更新後のデータ
UPDATEUSER文字型256不可更新したユーザーのアカウント名
Fig.3-23(正) テーブル間の連携図
fig3_23.gif

Fig.3-48(正) 履歴テーブルの作成
fig3_48.gif

prevpg.gif Chapter 6 20/92 nextpg.gif