世代管理をするデータベース設計手法について

小中学校向けの校務支援システムの開発を手掛けおります。
そこで世代管理する為のデータベース設計について、ご教授ください。

主には、「生徒名簿」を軸として「出席簿」「教科」「成績表」「通信表」「健康カード」などを扱う校務システムです。
その各レコードを、「小中9年間」＋「その後保存期間5年間」のレコードを保持しなくてはなりません。
以下その例となります。

▼生徒名簿A君
---------------------
学年　 |レコード数 |
小学1年生| 1レコード |
小学2年生| 2レコード |
小学3年生| 3レコード |
小学4年生| 4レコード |
小学5年生| 5レコード |
小学6年生| 6レコード |
中学1年生| 7レコード |
中学2年生| 8レコード |
中学3年生| 9レコード |
卒業1年目|10レコード|
卒業2年目|11レコード|
卒業3年目|12レコード|
卒業4年目|13レコード|
卒業5年目|14レコード|
---------------------
※上記のようにデータ保存として年毎にレコードが増幅します。
※このテーブルに紐づく色んな情報も同様にレコードの世代管理が必要となります。

この世代管理をどう設計すべきか悩んでいます。
自分なりに以下のような手法をイメージしております。

（案1）過去レコード(OFFフラグ)、現在のレコード(ONフラグ)のように「フラグ」で識別する。
（案2）「タイムスタンプ」で該当するレコードを識別する。
（案3）過去レコードは「別データベース化」するなど分離をする。
（案4）「SQL Server 2008 R2」でのこういった機能がある？(SQL Serverは初経験でわかっておりません)

どういった世代管理手法がありますでしょうか？
参考とさせて頂きたいです。お願いいたします。

---------------------
▼開発環境
・SQL Server 2008 R2
・NetFlamework4.0
・Microsoft Visual Studio 2010
・C#
・InternetExplorerのみに対応のWebアプリ
---------------------

尚、本来は自分や会社として解決すべき問題の質問で大変申し訳ありません。
指の数ほどの人数のインフラ会社で、システム開発の経験が無い会社でして、
転職して1カ月目の私が全て背負っております。
(そこを期待されて雇われたのですが。)
何卒よろしくお願いいたします。

No.3 回答者： OKNeko 回答日時： 2012/05/07 21:55

世代管理は不要です　>「その後保存期間5年間」のレコードを保持＜　の意味は小１～中３までの過去データを卒業後５年たったら削除と解釈します。

卒業1年目～卒業5年目の５レコードは必要ありません。データ削除は在籍フラグ項目を作り「在籍中：進級：卒業：転出：転入：休学：留学：除籍：etc」を管理し、年度末に「卒業：転出：除籍」が５年以上前を検索、該当生徒のデータを削除します。

ただし5年間のレコード保持が卒業生の進路追跡であれば別です。顧客（できれば担当部署の学校側）に聞取り、確認をおすすめします。個人情報でもあるので追跡調査は考えにくいです。

小中一貫教育の私立、又は市町村教育委員会からの受注のようですが、要件定義をもっと詰めること。顧客はシロウトさんなので気軽に「調査書」「卒業生名簿」等の出力帳票を追加してきます。注意しましょう。

発注者の意見だけで決定するのではなく、作業している学校での調査をおすすめします。


名簿は事務に在籍生徒コードがあり、各校で卒業まで変わらないはずです。名簿テーブルを2つに分けて

名簿テーブル　　　　　　　　　　　　　　　　　　在籍テーブル　　　
---------------------　　　　　　　　　　------------------------------------------
在籍生徒コード｜生徒名｜住所etc｜　　　在籍生徒コード｜年度 ｜学年　　　　｜在籍フラグ｜
　　　　００００１｜生徒Ａ｜　　　　　　　　　　　　　　００００１｜２０１１｜小学１年生｜進級　　　　｜
　　　　００００２｜生徒Ｂ｜　　　　　　　　　　　　　　００００１｜２０１２｜小学２年生｜在学中　　｜
　　　　００００３｜生徒Ｃ｜　　　　　　　　　　　　　　００００２｜２０１２｜小学２年生｜２年次転入｜
　　　　００００３｜生徒Ｃ｜　　　　　　　　　　　　　　００００３｜２０１１｜中学３年生｜卒業　　　　｜


名簿テーブルから在籍テーブにリレーションを貼って使ったほうがいいです
調査書の発行が要件に含まれていると転入前の学校の教科、成績も考慮する必要があります。
複数の学校に対応する市町村教育委員会等からの発注であれば、転入出も考えて、学校コード、在籍生徒コードの複合キーがいいでしょう。
複雑な要件の後出しがあると思って柔軟に頑張ってください。

この回答へのお礼

おっしゃる通りに、世代管理は不要ですね。
卒業生のレコードは発生しないですもんね(別に誰も管理しないですし)
世代管理が必要なものだ。と勝手に思い詰めておりました。

今回のプロジェクトはプロトタイプ開発でして、要件定義などの上流工程を出来ずにおりました・・・
(社長の命令で私自身も疑問符なのですが。)
しかし、要件定義や調査・分析はしっかりとやりたいと思います。
インフラ関係で職員室の現場などにも足を運べる環境なので、
現場主義を目指して、しっかりと要望を受け取りたいと思います。

在籍中、進級、卒業などの「在籍フラグ」というのは良いですね!!
思いつきませんでした。
「名簿テーブル」「在籍テーブル」の相対関係も発想に無かったです。
正直「年度」の扱いも悩んでいたので、「在籍生徒コード」などは、良いアイデアに思います。

色んなアドバイスありがとうございます!!
こういった校務システム開発のご経験者様でしょうか。
柔軟性と創造性を働かせて進めて参ります。
ありがとうございました!!

お礼日時：2012/05/08 08:10

No.2 回答者： mitoneko 回答日時： 2012/05/06 12:08

　生徒一人一人には、入学年をフィールドとして保持すれば、入学年から現在の学年は計算可能ですよね。

というわけで、現在何年生かをフィールドとして管理する必要はありません。

　ところで、例えば、「小学校１年生の１学期の通信簿を訂正した」という所まで記録として残さなければいけないのなら世代管理は結構面倒になるでしょうが、そうでなければ、通信簿は、だれそれの＊＊年度＊＊学期レコードとして保持すれば、世代管理は不要ですよね。
　出席簿・健康管理表も同様。

　やっかいなのは、個人レコードの住所かもしれません。これは、引っ越しの発生する可能性がありますから、引っ越しが申請された年月日と個人コードで管理となりますか。
　とすると、●年■月＊日時点での住所を求めたい時には、その時点より昔で且つ一番新しいデータを検索することになり、ちょっと面倒ですが、まぁ滅多に使わないでしょうから、少々の負荷は許容範囲でしょう。
　現在の住所を知りたいと言うのが一番使われるパターンになるはずです。この検索は、一番新しいデータを拾えば良いわけですが、これも最大値検索が必要ですから、少々負荷がかかります。それを避けるために、現在有効な住所にフラグを立てておくのは良いかもしれません。

　さて、削除は簡単です。入学年が今より１４年以上前の生徒のレコードを全てばっさりやればＯＫ。

　とすれば、世代管理らしいものは、住所のみですむと思われます。
　残りのデータは、全部一人の記録の積み重ねとして追加されていく種別のものですから、世代管理不要ですね。

この回答へのお礼

「入学年」をフィールドで持てば、おっしゃる通りに各レコードの識別ができそうですね。
何でレコードを識別しようか。少しスッキリとイメージできた気がします。
あと、ご指摘頂いたように「住所」の管理は大変になりそうですね。
システム要件として、どこまで「住所」の保持が必要なのか。
先方含めて、よく整理していきたいと思います。
アドバイスありがとうございます。

お礼日時：2012/05/06 15:45

No.1 回答者： nharasawa 回答日時： 2012/05/06 09:21

世代管理は、通常データがUPDTATEで変更されて行く場合に必要です。

質問の内容から見る限り、殆どのデータがINSERTによる追加のみで良いと思われるので、世代管理の必要性は無いと考えます。
１４年間持てば良いのであれば、１年に入学した年を記憶しておき、毎年１５年以前の関連データを削除するようにすれば、特に世代管理の必要は無いと考えます。

この回答へのお礼

なるほど。
確かに冷静に考えば、殆どのデータがINSERTによる追加となるシステムですね。
やはり「入学した年」を持って、レコードの識別をすべきですね。
少し頭の中で整理できてきそうな気がします。

お礼日時：2012/05/06 15:47