先生のための SQL Server 2016 | |||||
<< Prev | Next >> | ||||
第14回 学籍番号のデータ型を考える | |||||
データ型を決めるには、処理したいデータが数字なのか文字なのか、文字ならばアルファベットや数字だけで構成されるのか日本語を使うのか、などを決めておかなければならない。データベースの運用が始まってからの変更は、不可能ではないが困難が伴う。またデータベースの根幹にかかわるデータは他のテーブルやプログラミングに処理に影響するので、その意味でも吟味して決め、安易な変更を要しないようにしておきたい。 たとえば生徒を一意に決める「学籍番号」のデータは、学籍管理や成績処理のデータベースにおいては極めて中心的なデータになる。学籍番号をどう決めるかは、データベースの構築と運用に大きく影響する。 生徒は学校に入学し、卒業するまで同じ学籍番号でデータ処理することが必要になるだろう。単に一意のデータを与えるだけなら、入学生徒に対して1から始まる連番をつけてもよいだろう。 ある程度意味を持った学籍番号の付け方として、たとえば入学年度を4桁の数字で示し、その後ろに入学性の連番を付けることもよいだろう。学校の場合、年度単位で処理をする場面が多いので、学籍番号に入学年度を含めることには意味がある。このとき、仮に1学年が10クラス規模の学校であれば入学定員は400名となるので、入学年度の4桁と個々の生徒の連番3桁の7桁の数字で学籍番号を表現することになる。この形では、例えば2017年度の入学生には次のような番号が割り当てられることになる。 2017001 2017002 2017003 ・ ・ ・ 別のケースを考えよう。学校の多様化がすすむ今日において、ひとつの学校に複数の学科を有する場合も多くみられる。例えば私が現在勤務している学校は工業高校であり、機械科、電気科、建築科、情報技術科の4つの科がある。このような学校では、学籍番号に所属する科をあらわすコードが求められるかもしれない。この場合、学校規模にもよるが、たとえば学籍番号の桁を1つ増やし、学科コードを含むことも考えられる。このときは次のような8桁の番号になるだろう。 学籍番号=入学年度(4桁)+学科コード(1桁)+連番(3桁) 2017年度入学の機械科生徒 20171001 20171002 20171003 ・ ・ ・ 2017年度入学の電気科生徒 20172001 20172002 20172003 ・ ・ ・ 2017年度入学の建築科生徒 20173001 20173002 20173003 ・ ・ ・ 2017年度入学の情報技術科生徒 20174001 20174002 20174003 ・ ・ ・ いずれにせよ学校の事情にあわせて学籍番号を決めることになり、そのデータを合理的に処理するデータ型を決めることになる。さて、この学籍番号は「数字」だろうか。数字ならば整数をあらわすデータ型として「int」がある。int型は4バイトで表現される整数で、-2,147,483,648 から 2,147,483,647 までの整数を扱うことができるものだ。桁数は十分だろう。 しかし私は学籍番号は数字ではなく、固定長の文字列型で処理することを勧める。その理由は主に次の2つだ。 1.学籍番号に記号を使うこともできる。 2.絞り込みのクエリがシンプルになる。 1.については、たとえば複数学科を有する学校では、その学科を表す記号が決められていることがある。私の勤務校の例では、機械科はM、電気科はE、建築科はA、情報技術科はIといった記号で表している。このような記号は学校に定着しているので、数字ではなく記号で学籍番号を区別したいだろう。今日において学校は変化が求められるので、今はそうでなくても数年後には新しい学科が設置されるかもしれない。データを数値型にしていれば数字しか扱うことができないが、文字列型ならアルファベットなどの記号を使うこともでき、柔軟性がある。 2.についてはクエリの説明が必要になるだろう。クエリとはデータを絞り込む方法で、データベースでは SQL という言語で記述する。先の例で2017年度の入学生を学籍番号で絞り込むとき、数値の場合と文字列の場合では、クエリつまり SQL 文で次のような記述の違いがある。 データが数値の場合 SELECT gakuseid FROM SEITO WHERE gakuseid > 20170000 and gakuseid < 20180000 データが文字列の場合 SELECT gakuseid FROM SEITO WHERE gakuseid LIKE '2017%' つまり数値の場合は上限と下限を決めて絞り込む必要があるのに対して、文字列の場合は一部が同じであるデータを選択するという記述ができるのだ。このときに使う「%」の記号はワイルドカードといい、任意の文字列を表す記号だ。文字列の場合の方が直感的でわかりやすいだろう。直感的でわかりやすい記述は結果として間違いがおきにくいコードとなる。 また学科コードを用いたとき、特定の学科に所属する生徒だけを抽出したいとき、数値の場合は上限と下限を決めるような方法では記述が困難だが、文字列なら簡単に記述できる。先の例で5桁目に学科コードがあるとして、学科コード「4」の情報技術科に所属する生徒だけを選択するクエリは次のように記述できる。 SELECT gakuseid FROM SEITO WHERE gakuseid LIKE '____4%' ここで使われている「_」はアンダースコアで、任意の1文字を表している。この SQL 文で、先頭から5桁目の文字が「4」であるデータだけを絞り込むことができる。 このような理由から、学籍番号のようなデータは仮に見た目は数字であっても文字列型として処理をすることを勧める。ではデータを数値型として処理しなければならない場合は何かといえば、その値を集計する必要があるときだ。例えば「欠席日数」や「評定」などのデータは数値型にしておかなければ集計することができない。つまり見た目が数字であっても集計する必要がなく、絞り込む必要があるデータは文字列がいい、と言えるのだ。 |
|||||