ITmedia エンタープライズ

この特集のトップページへ
＞ Chapter 3：データストア層の構築

3.2.7　セキュリティと履歴
　クライアント/サーバーシステムでアプリケーションを構築するということは，多数の人間が共有してそのシステムを使うということである。そのため，セキュリティを保護する機構がないと，自分が書いた伝票を他人に書き換えられてしまうことにもなりかねない。そこで，「どのユーザーにどの情報の操作を許可するのか」というセキュリティの保護機構が必要となる。セキュリティの保護機構は，ビジネスロジック側に搭載することになるのだが，「伝票が誰によって作成されたか」などを表す情報をデータベース側に用意しておかないと，ビジネスロジック側でどのユーザーに対して権限を与えてよいのかわからなくなる。

　そこでここでは，セキュリティ情報をデータベーステーブルに格納するにはどのようにすればよいのかについて考える。

○ユーザーの特定

　まず，セキュリティを管理するうえで必要なのは，誰が伝票を書いたのか，誰が承認したのか，誰が発送したのか，誰が経理を担当したのか，といった情報を伝票に記録することである。そうしないと，あとでトラブルが生じたときに，誰がどの作業を担当したのかわからなくなり，問題の所在を突き止めることもできなくなってしまう。

　ユーザーを特定する方法は，いくつかある。最も手軽な方法は，自己申告制で担当者の名前をデータベーステーブルのフィールドに格納するというものである。しかし，これだと本人かどうかを確認できないので，一般的にこのような手法は採用されない。普通は，ビジネスアプリケーションを利用するアカウント名とパスワードをシステムに登録しておき，パスワードが合致したならば，本人であることを確認することになる。

　アカウント名とパスワードをシステムに登録するには，2つの方法がある。1つはデータベーステーブルに登録する方法，もう1つはWindows NTドメイン（Active Directoryドメインを含む）のアカウント情報を利用する方法である。前者は，たとえば利用可能なユーザーを格納するデータベーステーブルを用意し，そこにアカウント名とパスワードを登録し，ビジネスアプリケーションを利用するときにプレゼンテーション層でそのデータベースと照合する方法である。後者は，Windows NTドメインによって認証されたアカウント情報を利用する方法である。このサンプルでは，後者の方法でユーザーを特定することにする。

　Windows NTドメインによって認証する場合，Windows NT ServerやWindows 2000 Serverに認証処理を任せることができるため，実装は容易である。また，詳しくはChapter 4で説明するが，COM＋は登録されたCOMコンポーネントのどのメソッドを誰が呼び出すことができるのかという情報をロールという仕組みによって管理している。ロールは，Windows NTドメインのユーザーとマッピングされるようになっているので，COM＋を使ってビジネスロジックを構築する場合には，独自のデータベーステーブルで認証するよりも連携性が高くなる。ただし，その半面，ビジネスアプリケーションを利用するにあたっては，ユーザーがWindows NTドメインに参加していることが前提となる。そのため，Webから利用する場合など，Windows NTドメインの環境以外から利用するときには，若干の制約が生じる。とはいえ，Windows NT ServerやWindows 2000 Serverに添付されているIISには，特定のクライアント証明書を持つユーザーをWindows NTドメインの実ユーザーにマッピングする機能を備えている。そのため，この機能を利用するという逃げ道がある。

・Windows NTドメインにおけるアカウントの取り扱い

　では，Windows NTドメインにおけるアカウントとは，どのような情報で成り立っているのだろうか。一般にWindows NTドメインでは，ユーザーがログインしたときにアクセストークンという情報が渡され，その情報をもとに特定の操作をする権限があるかどうかを判定されるのが，それについてはとりあえず置いておく。ここで理解する必要があるのは，Windows NTドメインでは何をもとにして各ユーザーを識別しているのか，ということである。

　Windows NTドメインでは，ドメイン内のユーザーやグループごとにSID（Security IDentifier）という値が割り当てられ，これがユーザーのセキュリティ識別子となっている。よって，SIDの値をデータベースに保存しておけば，どのユーザーが操作したのかをデータベースに格納することができる。しかし，SIDをデータベースに格納するのは，やや面倒である。なぜなら，SIDは固定長ではなく，可変長だからである。

　そういった理由から，このサンプルでは，ユーザーを特定するのにSIDではなくアカウント名を使うことにする。アカウント名の最大長は，Platform SDKに付属のLMHONS.HというヘッダファイルにUNLENという定数として定義されている。LMHONS.Hファイルを参照するとわかるが，これは256と定義されている。よって，アカウント名の最大長は256文字であり，これだけの文字列を格納できるフィールドをデータベーステーブルに用意すればよい。

　そこで，いままで作成してきたデータベースに，操作したユーザーのアカウント名を登録するフィールドを加えることにする（Table 3-13〜Table 3-18）。

Table 3-13　顧客情報テーブル

フィールド名	型	サイズ	Null	解説
ID	数値型 （オートナンバー）	―	不可	顧客番号。レコードに対して唯一無二の値を割り当てる
NAME	文字型	64	不可	顧客名
YOMIGANA	文字型	80	可	顧客名のよみがな
ZIP	文字型	10	可	郵便番号
ADDRESS	文字型	255	可	住所
TELEPHONE	文字型	32	可	電話番号
FAX	文字型	32	可	FAX番号
MEMO	文字型	80	可	摘要
BILLDAY	数値型	−	可	請求書を作成する期間の締め日（1〜31）
MADEUSER	文字型	256	不可	この顧客情報を登録したユーザーのアカウント名
MADEDATE	日付型	−	不可	この顧客情報を登録した日時
LASTUSER	文字型	256	不可	最終更新者のアカウント名
LASTDATE	日付型	−	不可	最終更新日

Table 3-14　製品情報テーブル

フィールド名	型	サイズ	NULL	解説
ID	数値型 （オートナンバー）	―	不可	製品番号。レコードに対して唯一無二の値を割り当てる
PRODUCTNAME	文字型	64	不可	製品名
YOMIGANA	文字型	80	可	製品名のよみがな
PRICE	金銭型	―	不可	製品の価格
STOCK	数値型	―	不可	現在の在庫数
MEMO	文字型	80	可	摘要
BACKORDER	数値型	−	不可	在庫のうちすでに予約されている数
MADEUSER	文字型	256	不可	この製品情報を登録したユーザーのアカウント名
MADEDATE	日付型	−	不可	この製品情報を登録した日時
LASTUSER	文字型	256	不可	最終更新者のアカウント名
LASTDATE	日付型	−	不可	最終更新日

Table 3-15　伝票情報テーブル

フィールド名	型	サイズ	NULL	解説
ID	数値型 （オートナンバー）	−	不可	伝票を識別するための唯一無二の番号。伝票番号として使われる
CUSTOMERID	数値型	−	不可	この伝票の対象となる顧客を示す顧客番号。顧客情報テーブルのIDフィールドに格納されているいずれかの値が格納される
MADEDATE	日付型	−	不可	伝票の起票日
DIVISION	文字型	64	可	顧客側の部署名
PERSON	文字型	64	可	顧客側の担当者名
DELIVERDATE	日付型	−	不可	納入予定日
SENT_ADDR	文字型	255	可	発送先の住所。製品管理部が製品をこの住所に発送する
SENT_TEL	文字型	32	可	発送先の電話番号。製品管理部が製品発送の際の連絡先として用いる
SUBTOTAL	金銭型	−	不可	小計。この伝票に含まれるすべての注文の金額（税抜）を加えたもの
TAX	金銭型	−	不可	消費税。現状では，小計×1.05
TOTAL	金銭型	−	不可	合計（税込金額）。小計＋消費税
MEMO	文字型	80	可	摘要
BILLID	数値型	−	可	この伝票を集計結果として含む請求書の請求書番号。請求書情報テーブルのIDフィールドに格納されているいずれかの値が格納される
BILLDATE	日付型	−	可	この伝票を集計結果として含む請求書が作られた日
MADEBILLFLAG	Boolean型	−	−	この伝票を集計結果として含む請求書が作られているかどうかのフラグ。Trueで請求書が作られていることを，Falseで作られていないことを示す
ONEBILLFLAG	Boolean型	−	−	この伝票に対して独立した請求書を作るかどうかのフラグ。Trueで独立した請求書を作ることを，Falseで月単位で集計した請求書に含めることを示す
REQ_CONSENTFLAG	Boolean型	−	−	承認の依頼をしているかのフラグ。Trueで承認依頼中，Falseで承認依頼をまだしていないことを示す
REQ_CONSENTDATE	日付型	−	可	承認依頼をした日
REQ_CONSENTCOMMENT	文字型	80	可	承認依頼時のコメント。営業部上司へのコメントとなる
CONSENTEDFLAG	Boolean型	−	−	承認したかどうかのフラグ。Trueで承認した，Falseで承認していないことを示す。通常は営業部の上司が設定するが，伝票の取引額が一定以下であり上司の承認が不要である伝票については，システム側でこのフラグをTrueに設定する
CONSENTEDDATE	日付型	−	可	承認された日
CONSENTEDCOMMENT	文字型	80	可	承認の際のコメント
REJECTEDFLAG	Boolean型	−	−	上司によって却下されたかどうかを示すフラグ。Trueで却下されたことを，Falseで却下されていないことを示す
REJECTEDDATE	日付型	−	可	却下された日
REJECTEDCOMMENT	文字型	80	可	却下理由
SENDFLAG	Boolean型	−	−	この伝票に含まれている製品が発送されたかどうかのフラグ。Trueで発送ずみであることを，Falseで未発送であることを示す
SENDDATE	日付型	−	可	発送日
SENDCOMMENT	文字型	80	可	発送の際のコメント
ACCOUNTINGFLAG	Boolean型	−	−	経理部がその伝票をチェックしたかどうかのフラグ。チェックしたならばTrue，まだチェックしていなければFalse。このフラグがTrueになると，それが請求書を作成する際に集計の対象となる
ACCOUNTINGDATE	日付型	−	可	経理部が伝票をチェックした日
ACCOUNTINGCOMMENT	文字型	80	可	経理部のコメント
MADEUSER	文字型	256	不可	この伝票を起票したユーザーのアカウント名
REQ_CONSENTUSER	文字型	256	可	この伝票を承認依頼したユーザーのアカウント名
CONSENTEDUSER	文字型	256	可	この伝票を承認したユーザーのアカウント名
REJECTEDUSER	文字型	256	可	この伝票を却下したユーザーのアカウント名
SENDUSER	文字型	256	可	発送処理をしたユーザーのアカウント名
ACCOUNTINGUSER	文字型	256	可	経理処理をしたユーザーのアカウント名
LASTUSER	文字型	256	不可	最終更新者のアカウント名
LASTDATE	日付型	−	不可	最終更新日

Table 3-16　明細情報テーブル

フィールド名	型	サイズ	NULL	解説
ID	数値型 （オートナンバー）	−	不可	明細を識別するための唯一無二の番号
PRODUCTID	数値型	−	不可	この明細の対象となる製品を示す製品番号。製品情報テーブルのIDフィールドに格納されているいずれかの値が格納される
NUMBER	数値型	−	不可	注文された製品の数量
UNITPRICE	金銭型	−	不可	製品の単価。通常は，製品情報テーブルのPRICEフィールドの値と同じものが格納される
PRICE	金銭型	−	不可	価格。注文された個数（NUMBER）×製品の単価（UNITPRICE）が格納される
MEMO	文字型	80	可	摘要
SLIPID	数値型	−	不可	この明細を含んでいる伝票の伝票番号。伝票情報テーブルのIDフィールドに格納されているいずれかの値が格納される
MADEUSER	文字型	256	不可	この明細情報を登録したユーザーのアカウント名
MADEDATE	日付型	−	不可	この明細情報を登録した日時
LASTUSER	文字型	256	不可	最終更新者のアカウント名
LASTDATE	日付型	−	不可	最終更新日

Table 3-17　請求書情報テーブル

フィールド名	型	サイズ	NULL	解説
ID	数値型 （オートナンバー）	−	不可	請求書を識別するための唯一無二の番号。請求書番号として使われる
CUSTOMERID	数値型	−	不可	この請求書の対象となる顧客を示す顧客番号。顧客情報テーブルのIDフィールドに格納されているいずれかの値が格納される
STARTDATE	日付型	−	不可	この請求書の集計期間の開始日（この日を含む）
ENDDATE	日付型	−	不可	この請求書の集計期間の終了日（この日を含む）
MADEDATE	日付型	−	不可	請求書の作成日
SUBMITDATE	日付型	−	可	入金の確認日
PAIDFLAG	Boolean型	−	−	入金があったかどうかのフラグ。Trueで入金ずみ，Falseで未入金を示す
SENDBILLFLAG	Boolean型	−	−	請求書を送付済みかどうかのフラグ。Trueで送付済み，Falseで未送付を示す
SUBTOTAL	金銭型	−	不可	小計。この請求書の金額（税抜）合計 。STARTDATE〜ENDDATEの期間内の伝票の小計（SUBTOTALフィールド）の和
TAX	金銭型	−	不可	消費税。STARTDATE〜ENDDATEの期間内の伝票の消費税（TAXフィールド）の和
TOTAL	金銭型	−	不可	この請求書の合計（税込金額）。STARTDATE〜ENDDATEの期間内の伝票の合計（TOTALフィールド）の和
MEMO	文字型	80	可	摘要
SUBMITUSER	文字型	256	可	入金を確認したユーザーのアカウント名
MADEUSER	文字型	256	不可	請求書を作成したユーザーのアカウント名
LASTUSER	文字型	256	不可	最終更新者のアカウント名
LASTDATE	日付型	−	不可	最終更新日

Table 3-18　在庫情報テーブル

フィールド名	型	サイズ	NULL	解説
ID	数値型 （オートナンバー）	−	不可	レコードに対して唯一無二の値を割り当てる
DATE	日付型	−	不可	入庫および出庫の予定日
DUEDATE	日付型	−	可	入庫および出庫が実際に行われた日
CONFIRMEDFLAG	Boolean型	−	−	入庫および出庫が実際に行われたかどうかのフラグ。行われていればTrue，まだ行われていなければFalse
PRODUCTID	数値型	−	不可	この明細の対象となる製品を示す製品番号。製品情報テーブルのIDフィールドに格納されているいずれかの値が格納される
NUMBER	数値型	−	不可	入庫および出庫の数量。入庫の場合には正の数を，出庫の場合には負の数を格納する
MEMO	文字型	80	可	摘要
SLIPID	数値型	−	可	出庫のとき，この出庫が生じるもととなった伝票の伝票番号。伝票情報テーブルのIDフィールドに格納されているいずれかの値が格納される
MADEUSER	文字型	256	不可	この入出庫情報を登録したユーザーのアカウント名
MADEDATE	日付型	−	不可	この入出庫情報を登録した日時
LASTUSER	文字型	256	不可	最終更新者のアカウント名
LASTDATE	日付型	−	不可	最終更新日

○削除記録を残す

　さて，以上のフィールドを追加することで，レコードを作ったユーザーと最終的に更新したユーザーを登録できるようになった。しかし，「これだけでよい」というわけではない。たとえば，あるレコードがAというユーザーによって作られたとする。そして，Bというユーザーがそのレコードを削除しようとしたとする。このとき，レコード自身が削除されてしまうため，Bというユーザーによって削除されたという記録が残らない。

　誰が削除したのかを記録するためには，実際にレコードを削除するのではなく，レコードに対して削除ずみというフラグを立てることにすればよい。そして，削除ずみのフラグが立っているレコードはユーザーから見えないようにすれば，そのレコードは外部からは消えたように見えるが，内部的にはちゃんと残っていることになる。したがって，レコードの最終更新者のフィールドを参照すれば，誰が削除したかを知ることができる。

　そこで，Table 3-13〜Table 3-18に示したすべてのテーブルに，削除ずみであるかどうかを示すDELETEDFLAGフィールドを追加することにする（Table 3-19）。

Table 3-19　削除ずみのフィールド（Table 3-13〜Table 3-18のすべてのテーブルに追加）

フィールド名	型	サイズ	NULL	解説
DELETEDFLAG	Boolean型	−	−	削除されたかどうかのフラグ。Trueで削除されたことを，Falseで削除されていないことを示す

　レコードを削除する必要があったとき，ビジネスロジックは，レコードを実際に削除するのではなく，上記のDELETEDFLAGフィールドの値をTrueに設定する。そして，ユーザーにデータを参照させるときや集計作業のときには，DELETEDFLAGフィールドがTrueに設定されているレコードを除外することで，内部的には削除されていないが，ユーザーからは削除されたように見せるのである。

○履歴を残す

　これで削除されたという記録は残るようになるが，誰かがレコードを変更した場合に，どのフィールドの内容がどのように変更されたのかを記録することはできない。なぜなら，レコードを変更するときに，古い値は新しい値で上書きされてしまうためである。しかし，不正な修正を防ぐという意味では，「誰が，いつ，どの情報を，何から何に変更したのか」という記録が必要になることもある。

　この問題を解決するのは，比較的容易である。レコードを上書きするのではなく，先に追加しておいたDELETEDFLAGフィールドをTrueに設定して削除ずみとし，新しいレコードを別途追加すればよいのである（Fig.3-17）。

Fig.3-17　古いレコードは削除ずみにして新しいレコードを別途追加する

　これにより，古いレコードが残るため，新しく追加されたレコードと古いレコードとを比較すれば，どのフィールドの値が変更されたのかを知ることができるようになる。

　しかし，新しくレコードを追加することにより，主キーとなっているフィールドの値が変わってしまう点に注意したい。ほかのテーブルと連携している場合には，主キーとなっているフィールドの値が変わることで，連携しているレコードがずれてしまうことがある（Fig.3-18）。

Fig.3-18　主キーとなっているフィールドの値が変わる場合

　つまり，Fig.3-17の方法ですべてがうまくいくとは限らないのである。そこで，簡単ではあるが，Table 3-20に示す履歴テーブルを用意し，レコードの更新があるたびに，更新されたテーブル名，フィールド名，古い値，新しい値，更新者，更新日時を逐一記録してゆくことにする（Fig.3-19）。

Table 3-20　履歴テーブル

フィールド名	型	サイズ	NULL	解説
ID	数値型 （オートナンバー）	−	不可	レコードに対して唯一無二の値を割り当てる
DATE	日付型	−	不可	変更が生じた日時
TABLENAME	文字型	32	不可	変更が生じたデータベーステーブル名
FIELDNAME	文字型	32	不可	変更が生じたデータベーステーブルのフィールド名
RECORDID	数値型	−	不可	変更が生じたレコードのレコードID（そのデータベーステーブルにおいて主キーとなっているフィールドの値）
OLDDATA	文字型	256	可	更新まえのデータ
NEWDATA	文字型	256	可	更新後のデータ
UPDATEUSER	文字型	256	不可	更新したユーザーのアカウント名

Fig.3-19　履歴テーブルに履歴を残す

　なお，履歴テーブルには，古い値と新しい値を文字列として記録することにした。文字列として記録すると，プログラムからの処理は難しくなるが，このサンプルでは履歴テーブルをたどってデータをもとの状態に戻すような処理はせず，ビジネスアプリケーションの管理者がそれを参照できるような機能だけを提供するにとどめたい。データをもとの状態に戻すには，データベースエンジンのトランザクションログを利用すればよいため，文字列として人間が履歴を参照できるだけの機能を提供すれば，実用面での問題はないだろう。

○伝票に対しての高度な履歴処理

　ところで，伝票に対する修正は，より厳格に処理しなければならない。紙の伝票では，誰かが伝票を書き換えても，その書き換えの痕跡が残る。しかしデータベースで管理する場合には，伝票が書き換えられたという痕跡は残らない。もっとも，Table 3-20に示した履歴テーブルをたどることで，その履歴を残すことはできるのだが，ここでいいたいのは，伝票自身にその履歴を確保する仕組みを持たせる必要があるということである。

　一般的に，紙の伝票であれば，修正が生じたときには修正した箇所に訂正印を押すなどして，誰によってどこが修正されたのかを明らかにする（Fig.3-20）。データベースで管理する場合にも，途中で修正が生じたときには，伝票上にその記録を残す必要があるだろう（もっとも，大きな修正であれば，一般的に古い伝票を破棄し，修正を認めず新しい伝票を起票することになるだろう）。

Fig.3-20　伝票の修正

　実は，伝票内の明細を修正することは，Table 3-19で指定したDELETEDFLAGフィールドを利用することで簡単に実現できる。どういうことかというと，明細の修正は許さないことにして，明細を修正する必要がある場合には，その明細に対してDELETEDFLAGフィールドをTrueに設定し，新しい明細レコードを別途追加するのである。そして，ユーザーに伝票を表示するときには，DELETEDFLAGフィールドがTrueに設定されている明細に対して取消線を描くように実装すればよいのである（Fig.3-21）。

Fig.3-21　明細の修正

　この方法で，明細の修正を伝票に表示できるようになるが，伝票情報テーブル内に記載されている個々の情報（納品予定日や担当者名，発送先の住所など）の変更記録を伝票に表示させることは難しい。実現しようとすれば，Table 3-20の履歴テーブルに残した履歴を順にたどり，どのデータがどう変更されたのかを調べる複雑な処理が必要となるだろう。

　そこで，納品予定日や担当者，発送先の住所など，編集履歴を残す必要がある情報は，伝票追加情報という別のテーブルに分け，伝票情報テーブルと明細情報テーブルのように相互に連結する（Table 3-21，Table 3-22，Fig.3-22）。

Table 3-21　伝票情報テーブル

フィールド名	型	サイズ	NULL	解説
ID	数値型 （オートナンバー）	−	不可	伝票を識別するための唯一無二の番号。伝票番号として使われる
CUSTOMERID	数値型	−	不可	この伝票の対象となる顧客を示す顧客番号。顧客情報テーブルのIDフィールドに格納されているいずれかの値が格納される
MADEDATE	日付型	−	不可	伝票の起票日
SUBTOTAL	金銭型	−	不可	小計。この伝票に含まれるすべての注文の金額（税抜）を加えたもの
TAX	金銭型	−	不可	消費税。現状では，小計×1.05
TOTAL	金銭型	−	不可	合計（税込金額）。小計＋消費税
BILLID	数値型	−	可	この伝票を集計結果として含む請求書の請求書番号。請求書情報テーブルのIDフィールドに格納されているいずれかの値が格納される
BILLDATE	日付型	−	可	この伝票を集計結果として含む請求書が作られた日
MADEBILLFLAG	Boolean型	−	−	この伝票を集計結果として含む請求書が作られているかどうかのフラグ。Trueで請求書が作られていることを，Falseで作られていないことを示す
ONEBILLFLAG	Boolean型	−	−	この伝票に対して独立した請求書を作るかどうかのフラグ。Trueで独立した請求書を作ることを，Falseで月単位で集計した請求書に含めることを示す
REQ_CONSENTFLAG	Boolean型	−	−	承認の依頼をしているかのフラグ。Trueで承認依頼中，Falseで承認依頼をまだしていないことを示す
REQ_CONSENTDATE	日付型	−	可	承認依頼をした日
REQ_CONSENTCOMMENT	文字型	80	可	承認依頼時のコメント。営業部上司へのコメントとなる
CONSENTEDFLAG	Boolean型	−	−	承認したかどうかのフラグ。Trueで承認した，Falseで承認していないことを示す。通常は営業部の上司が設定するが，伝票の取引額が一定以下であり上司の承認が不要である伝票については，システム側でこのフラグをTrueに設定する
CONSENTEDDATE	日付型	−	可	承認された日
CONSENTEDCOMMENT	文字型	80	可	承認の際のコメント
REJECTEDFLAG	Boolean型	−	−	上司によって却下されたかどうかを示すフラグ。Trueで却下されたことを，Falseで却下されていないことを示す
REJECTEDDATE	日付型	−	可	却下された日
REJECTEDCOMMENT	文字型	80	可	却下理由
SENDFLAG	Boolean型	−	−	この伝票に含まれている製品が発送されたかどうかのフラグ。Trueで発送ずみであることを，Falseで未発送であることを示す
SENDDATE	日付型	−	可	発送日
SENDCOMMENT	文字型	80	可	発送の際のコメント
ACCOUNTINGFLAG	Boolean型	−	−	経理部がその伝票をチェックしたかどうかのフラグ。チェックしたならばTrue，まだチェックしていなければFalse。このフラグがTrueになると，それが請求書を作成する際に集計の対象となる
ACCOUNTINGDATE	日付型	−	可	経理部が伝票をチェックした日
ACCOUNTINGCOMMENT	文字型	80	可	経理部のコメント
MADEUSER	文字型	256	不可	この伝票を起票したユーザーのアカウント名
REQ_CONSENTUSER	文字型	256	可	この伝票を承認依頼したユーザーのアカウント名
CONSENTEDUSER	文字型	256	可	この伝票を承認したユーザーのアカウント名
REJECTUSER	文字型	256	可	この伝票を却下したユーザーのアカウント名
SENDUSER	文字型	256	可	発送処理をしたユーザーのアカウント名
ACCOUNTINGUSER	文字型	256	可	経理処理をしたユーザーのアカウント名
LASTUSER	文字型	256	不可	最終更新者のアカウント名
LASTDATE	日付型	−	不可	最終更新日
DELETEDFLAG	Boolean型	−	−	削除されたかどうかのフラグ。Trueで削除されたことを，Falseで削除されていないことを示す

Table 3-22　伝票追加情報テーブル

フィールド名	型	サイズ	NULL	解説
ID	数値型 （オートナンバー）	−	不可	レコードを識別するための唯一無二の番号
SLIPID	数値型	−	不可	この情報と結びつけられている伝票の伝票番号。伝票テーブルのIDフィールドに格納されているいずれかの値が格納される
DIVISION	文字型	64	可	顧客側の部署名
PERSON	文字型	64	可	顧客側の担当者名
DELIVERDATE	日付型	−	不可	納入予定日
SENT_ADDR	文字型	255	可	発送先の住所。製品管理部が製品をこの住所に発送する
SENT_TEL	文字型	32	可	発送先の電話番号。製品管理部が製品発送の際の連絡先として用いる
MEMO	文字型	80	可	摘要
MADEDATE	日付型	−	不可	伝票の起票日
MADEUSER	文字型	256	不可	この伝票を起票したユーザーのアカウント名
LASTDATE	日付型	−	不可	最終更新日
LASTUSER	文字型	256	不可	最終更新者のアカウント名
DELETEDFLAG	Boolean型	−	−	削除されたかどうかのフラグ。Trueで削除されたことを，Falseで削除されていないことを示す

Fig.3-22　伝票情報テーブルと伝票追加情報テーブルとの関係

　このように，伝票情報テーブルから伝票追加情報テーブルを分離することによって，納品予定日や担当者，発送者の住所が変更になった場合でも，明細の修正と同じようにして，古いレコードのDELETEDFLAGフィールドをTrueに設定し，新しいレコードを別途連結することによって，その修正履歴を伝票上に簡単に表示できるようになる。

Chapter 3　11/22