プロパティと型 ── 何をどんな形で覚えるか

1-2「エンティティ」では、台帳が覚えておくエンティティを整理し、主キーや外部キーでデータの結びつきを決めました。この章では、それぞれのエンティティが何をどんな形で記憶するのかを考え、プロパティや型、制約、そして NOT NULL や列挙型を使って取りうる値を決めていきます。これらをひとまとめにした「スキーマ」というデータの形の定義を組み立てられるようになりましょう。

プロパティを挙げる

1-2「エンティティ」 では、台帳が覚えておく 4 つのエンティティを拾い出し、見分けのための主キーと、結びつきを表す外部キーを決めました。エンティティの枠組みが決まったところで、この章では、それぞれのエンティティが具体的に何を覚えるかを決めていきます。エンティティが覚える 1 つ 1 つの事柄のことを、プロパティ(Property)と呼びます。以後はこの語で呼びます。

たとえば、備品というエンティティであれば、名前、種類、購入日という事柄を覚えます。保管場所なら名前、利用者なら氏名、貸出なら貸した日を覚えます。なお、それぞれのエンティティを見分ける主キーや、相手を指し示す外部キーは前の章ですでに決めてあるため、ここで改めて挙げ直す必要はありません。

エンティティにどんなプロパティを持たせるかを考えるとき、何を基準に選べばよいでしょうか？その物差しとなるのは、「この台帳の機能のどれかが使うか」という一点です。一覧に出す、あるいは備品を借りるときに確かめる、といった台帳の機能のどれかが使うプロパティだけを挙げます。反対に、どの機能からも使われない事柄は、プロパティとして足してはいけません。たとえば、備品の「色」を考えてみましょう。貸し出し台帳の機能において、色によって貸出を判断したり一覧で探したりする必要がなければ、色はプロパティに含めません。「いつか使うかもしれない」という曖昧な見込みは、プロパティを足す理由にはならないのです。

ここで、貸出エンティティに関して「返却された日」や「返却されたかどうか」を記録したくなるかもしれません。しかし、返却をどう記録するかは、この章では決めずに残しておきます。出来事の移り変わりをどう設計するかは、1-5「状態」 で扱うからです。まずは備品台帳に必要なプロパティを確実に整理していきましょう。設計メモの備品には、次のように 3 つのプロパティが並びます。

このように、台帳の機能が必要とする事柄だけを絞り込んでプロパティとして挙げることで、無駄のないすっきりとしたデータの形が見えてきます。

型は、取りうる値の集まり

プロパティを挙げた後は、それぞれのプロパティにどんな値を入れてよいかを決めていきます。プロパティごとに、そこに入ることが許される値の範囲や性質をあらかじめ定めておく必要があります。プロパティが取りうる値の集まりのことを、型(Type)と呼びます。以後はこの語で呼びます。

世の中のシステムには、代表的ないくつかの型が存在します。文字の並びのことを文字列と呼びます。また、0 や 12、-3 のような小数点の無い数のことを整数と呼びます。これらに加えて、カレンダーの年・月・日を表す日付も重要な型です。たとえば、備品の「購入日」というプロパティの型を日付と決めたとします。すると、購入日には日付という型の値だけが入るようになり、「来週あたり」という文字列は入りません。

型をあらかじめ決めておくと、形の合わない値をシステムの入口で断ることができます。もし型を決めておかないと、日付を入れるべき場所にデタラメな文字列が紛れ込んでしまいます。型を決めることで、想定していない形の値を早い段階で排除でき、断る場所が 1 つに決まります。

ただし、型について忘れてはならない重要な点があります。それは、型が断れるのは形の合わない値だけだということです。日付の形をした誤り、たとえば実際に買った日とは違う日付が入力されたとしても、それは日付という形としては正しいため、型を通り抜けてしまいます。中身が正しいかまでは型は保証しません。型はあくまで値の形を揃える仕組みであり、事実と合っているかという中身の正しさまで保証するわけではない点に注意が必要です。

制約は型に置き、一度だけ決める

型を決めると値の大まかな形が決まりますが、それだけでは十分でないことがあります。たとえば、備品の名前を単に文字列とするだけでは、文字数が極端に多すぎる文字列や、何も書かれていない 0 文字の文字列が入ってしまうかもしれません。そこで、「備品の名前は 1〜40 文字」といったように、値に具体的な決まりを設けます。このような値の決まりのことを、制約と呼びます。そして、システムに入ってきた値が型と制約に合うかを入口で確かめることを、バリデーションと呼びます。以後はこれらの語で呼びます。

ここで、台帳のほかのプロパティにも目を向けてみましょう。備品の名前だけでなく、保管場所の名前や、利用者の氏名も、同じように短めの文字数に収めたいはずです。具体的には、これら 3 つのプロパティをどれも「前後の空白を除いて 1〜40 文字」で同じ決まりに揃えたいと考えたとします。このとき、備品の名前、保管場所の名前、利用者の氏名というプロパティごとに同じ決まりを 3 回書くのは得策ではありません。もし後から決まりを変更したくなったときに、プロパティごとに書いていると、どれか 1 つを直し忘れてしまうからです。

そこで、決まりを 1 つの型にして名前を付けます。具体的には、「短い名前」という型を作り、3 つのプロパティがそれを使うように設計します。このようにしておけば、決まりを変えるときは型を 1 か所直せばよく、すべてのプロパティに一括で反映されます。値が正しく守られているかを確かめるバリデーションも、プロパティごとではなく型ごとに 1 つになります。

制約はプロパティではなく型に付ける。これがこの章でいちばん大事なことです。設計メモでは、エンティティとは別に型の節を置き、そこで「短い名前」という型を定義します。

このように制約を型として一度だけ決めておくことで、重複や直し忘れを防ぎ、すっきりと整理された台帳を作ることができます。

NULL を許すかを決める

1-2「エンティティ」で、値が無いことを NULL と呼びました。それぞれのエンティティのプロパティについても、値が無い状態を認めるかどうか、すなわち NULL を許すかを決める必要があります。

たとえば、社内に昔からある古いプロジェクタを台帳に登録する場面を考えてみましょう。あまりに古い備品であるため、正確な購入日が分からないことがあります。購入日が分からないからといって台帳に登録できないのでは困ります。そこで、購入日というプロパティは NULL を許すことにします。設計メモでは、NULL を許すプロパティに「NULL 可」と書きます。

一方で、NULL を許さないことを NOT NULL と呼びます。以後はこの語で呼びます。備品の名前や種類は、どんな備品にも必ずあるものなので NOT NULL にします。この台帳の設計メモでは NOT NULL を既定にし、NULL を許すものだけに「NULL 可」と書く方針をとります。

NULL を許すかをあらかじめ決めておかないと、システムを作る人が「0 年 0 月 0 日」や空の文字列で埋めるかもしれません。しかし、NULL は「値が無い」ことであり、数字の 0 や空の文字列とは違います。値が無い状態を正しく扱うために、どのプロパティに NULL を許すかを設計の段階で明確に選んでおくことが大切です。

選択肢は列挙型で書く

備品を管理する際、それぞれの備品を分類するために「備品の種類」というプロパティを持たせることを考えます。もしこの備品の種類に利用者が自由に文字列を書けるようにしてしまうと、人によって「PC」「パソコン」「ノート PC」といったように同じ意味でも書き方がばらついてしまいます。表記がばらつくと、台帳で同じ種類の備品を正しくまとめることができず、種類で絞った一覧が作れなくなってしまいます。

そこで、入力できる選択肢をあらかじめ限定し、選べる値を並べてそれ自体を 1 つの型として定義します。このように、選べる値を並べた型のことを列挙型と呼びます。以後はこの語で呼びます。備品台帳では、「備品の種類:列挙型。プロジェクタ・カメラ・ノート PC・その他 のどれか」と決めて型にします。

ここで、並べた選択肢の中に「その他」を置いているのには実務上の理由があります。それは、並べた中に無い備品が来たときに、登録を止めないためです。オフィスには、プロジェクタやカメラ以外にも様々な備品が持ち込まれます。選択肢に当てはまる項目が無いからといって備品の登録が止まってしまっては困ります。並べた中に無い備品でも登録を受け付けられるように、「その他」という選択肢をあらかじめ用意しておくのです。

このように選択肢を列挙型で書くことで、表記のばらつきを未然に防ぎ、台帳の備品を種類ごとにすっきりと整理して扱えるようになります。

この章のまとめ ── スキーマ

ここまで整理してきたことで、設計メモには共通の型の定義が足され、それぞれのエンティティごとに記憶すべきプロパティが整然と並びました。このように、エンティティ、主キー、外部キー、プロパティ、そして型をまとめた、データの形の定義のことをスキーマと呼びます。以後はこの語で呼びます。台帳がどのような構造でデータを持つのかを示す全体像であるため、設計メモの見出しも「スキーマ」にしました。

また、設計メモの末尾には「まだ決めていないこと」という節を置きました。設計を進める中で、現時点ではあえて決めていない事柄があるときは、決めていないと明確に書いておくことが大切です。決めていないことを放置すると、後から実装する人が推測で勝手に作ってしまい、意図しない仕組みになってしまう危険があるからです。

これで、備品台帳が扱うデータの骨組みがスキーマとして定まりました。次の章(1-4「ER 設計」)は、このスキーマを ER 図に描き、採らなかった別の捉え方と比べます。