エンティティ ── 何を覚えておくか

社内の備品の貸し出し台帳を設計するとき、まず決めるべきなのは台帳が何を覚えておくかというデータの単位です。この章では、管理する対象を整理し、それぞれを重複なく見分ける方法や、データ同士の結びつき、そしてデータが削除されたときの扱い方を決めていきます。設計メモの土台となる考え方を身につけ、サービスの骨組みを言葉でしっかりと組み立てられるようになりましょう。

説明文から、エンティティを拾う

1-1「データと機能」で確認した備品の貸し出し台帳の説明文をもう一度読み返してみましょう。台帳の設計を始めるとき、最初に行うのは説明文を丁寧に読み、出てくる名詞に印を付けていく作業です。拾い出した名詞を眺めると、それらはすべて同じように扱えるわけではありません。拾った名詞を「台帳が覚えておくデータの単位」と「そうでない名詞」の 2 つに分けて整理する必要があります。

説明文から拾った名詞のうち、台帳が覚えておく単位となるのは、備品、保管場所、利用者、貸出の 4 つです。これらは、台帳という仕組みが責任を持って記憶し続けなければならないデータのまとまりです。

一方で、拾った名詞の中には、台帳が覚えておく単位には当てはまらない名詞も多く混ざっています。たとえば「佐藤さん」は、覚えておく単位そのものではなく、利用者の 1 人にすぎません。「表計算のファイル」は業務の道具であり、これから作る台帳という仕組みそのものに置き換わる対象です。また、「名前」や「日付」といった言葉は、それぞれの単位の中に含まれる細かな中身であり、これらは 1-3「プロパティと型」 で詳しく扱います。さらに「一覧」という言葉も、台帳が覚えているデータを画面に並べて見せた結果にすぎず、台帳自身が別個に記憶しておく単位ではありません。

名詞を整理するときに注意したい点が 2 つあります。1 つ目は、社員と管理者の扱いです。説明文には「社員」と「管理者」という 2 つの呼び名が出てきます。しかし、台帳の仕組みから見れば、どちらも台帳を使って備品を借りたり確認したりする人です。そのため、設計の最初の段階では両者を別々に分けず、まとめて「利用者」という 1 つの単位として扱います。社員と管理者の間で権限にどのような違いがあるかは、1-7「認可」 で扱います。社員と管理者を別のエンティティにする捉え方もあり、1-4「ER 設計」 で比べます。

2 つ目は、「貸し出し」という言葉の扱いです。「貸し出し」は動詞から来た名詞ですが、これも台帳が覚えておく単位になります。なぜなら、いつ、誰が、どれを借りたのかという出来事を後から見るために、出来事そのものを記録として覚えておく必要があるからです。設計メモでは、この単位を簡潔に「貸出」と書きます。

このように、台帳が覚えておく、1 つ 1 つ見分けて扱うデータの単位のことを、エンティティ(Entity)と呼びます。以後はこの語で呼びます。備品、保管場所、利用者、貸出は、私たちが設計していく備品台帳の 4 つのエンティティです。

エンティティと値は違う

台帳が扱うデータを正しく整理するためには、エンティティと値の違いを明確に理解しておくことが欠かせません。この 2 つは、一見すると似ているように思えても、性質がまったく異なります。

たとえば、社内に同じ型番のプロジェクタが 2 台ある場面を考えてみましょう。この 2 台は、製品としての仕様や見た目といった中身がどれほどまったく同じであっても、台帳の上では 2 つの別のエンティティです。なぜなら、1 台を貸し出しても、もう 1 台は棚に残っていて誰でも借りられる状態にあるからです。中身が一致していても、それぞれが独立して存在し、別々に扱われます。

一方で、「2026 年 10 月 13 日」という日付や、「プロジェクタ」という備品の種類について考えてみましょう。日付や種類は、中身が同じであればまったく同一として扱われます。書類や画面のどこに書かれていても、内容が同じ日付や種類を別個に区別することはありません。このように、中身そのものによって決まり、どこに書かれても区別しないデータを値と呼びます。

さらに、エンティティには時間とともに中身が変わっていくという特徴があります。あるプロジェクタの保管場所が「3 階の棚」から「会議室 A」に移ったとします。このとき、保管場所という中身は変わりますが、プロジェクタそのものが別の備品に変わったわけではありません。時間とともに中身が変わっても、同じエンティティのままであり続けます。

ID と主キーで「同じエンティティか」を決める

エンティティは、中身が同じでも別のエンティティであり、中身が変わっても同じエンティティのままです。同じ型番のプロジェクタが 2 台あっても別の備品であり、保管場所が変わっても同じ備品でした。そのため、あるエンティティが「他と同じかどうか」は、名前や保管場所といった中身を比べるだけでは決められません。そこで、エンティティ 1 つに 1 つ、決して変わらない見分けの番号を振って決めます。この番号を ID と呼びます。

ここで、名前を ID にしてはいけないという大切な原則があります。なぜでしょうか？名前には 2 つの弱点があるからです。1 つは、同姓同名の 2 人の利用者がいる場合のように、名前が重なることがある点です。名前に頼ると、どちらの利用者が借りたのか見分けられなくなってしまいます。もう 1 つは、呼び名を直した備品のように、名前は後から変わる可能性がある点です。名前が変わるたびに過去の記録を見失ってしまうようでは困ります。重複したり途中で変わったりする名前は、見分けの基準には使えません。

データベースでは、エンティティごとに ID を入れる欄を 1 つ決めます。この欄を主キー(Primary Key、略して PK)と呼びます。

今回の備品台帳では、ID はすべて台帳自身が振ります。具体的には、備品 ID、保管場所 ID、利用者 ID、貸出 ID という番号を用意します。これらがそれぞれ各エンティティの主キーになります。そして、一度振った ID は、ほかのエンティティに使い回さないという約束を厳格に守ります。たとえ備品が廃棄されても、その備品 ID を新しい別の備品に使い回してはいけません。過去の記録と新しいデータが混ざってしまうのを防ぐためです。

リレーションと外部キー

第 1 節で整理したように、台帳には 4 つのエンティティがあります。しかし、エンティティはそれぞれが単独で存在しているだけでは意味が足りません。たとえば「貸出」というエンティティを考えてみてください。単に「誰かが何かを借りた」という事実だけがあっても、具体的に「どの備品を」「どの利用者が」借りたのかという相手を指し示していなければ、業務の台帳として役に立ちません。このように、エンティティ同士の結びつきをリレーションと呼びます。

エンティティ同士のリレーションは、相手の ID を自分のデータの中に持つことで表します。貸出エンティティの中に「備品 ID」と「利用者 ID」という欄を持たせることで、特定の備品や利用者との結びつきを表します。このように、相手の ID を入れる欄を外部キー(Foreign Key、略して FK)と呼びます。

ここで、結びつきの数に注目してみましょう。たとえば、プロジェクタ 1 台に対して、時とともに 3 回分の貸出が付いたとします。先週に 1 回借りられ、昨日に 1 回借りられ、今日も 1 回借りられたという場面です。このとき、1 台のプロジェクタという備品に対して、3 つの異なる貸出の記録が結びついています。このように、片方 1 つに相手がいくつも付くリレーションを 1 対多と呼びます。

1 対多のリレーションでは、外部キーは「多」の側が持つという大切な原則があります。備品が貸出の一覧を持つのではなく、貸出の 1 つ 1 つが備品 ID を持ちます。備品と保管場所も 1 対多のリレーションです。1 つの保管場所には、いくつもの備品が置かれます。したがって、「多」の側である備品が保管場所 ID を外部キーとして持ちます。

なぜ「多」の側に外部キーを持たせるのでしょうか？それは、記録と一覧が食い違うのを防ぐためです。もし備品の側に貸出の一覧を別に持ってしまうと、貸出の記録と備品側の一覧という 2 つの場所に情報を書くことになります。すると、更新の漏れによって記録と一覧が食い違ってしまう危険が生まれます。外部キーを「多」の側である貸出に持たせておけば、一覧を別に持たなくても、「この備品 ID を持つ貸出を集める」という手順によって後から確実に一覧を作ることができます。一覧を別に持たず、多の側が外部キーを持つことで、記録と一覧が食い違うのを防ぎます。

参照先が削除されたらどうするか

外部キーによってエンティティ同士を結びつけると、次に考えなければならない重要な問題が生じます。それは、外部キーが指している相手(参照先)が削除されるとき、外部キーを持つ側をどうするかという問題です。この方針を決めずに作り始めてしまうと、1-1「データと機能」で触れたように、削除の機能を作るときに作る人が仕様を黙って決めてしまうことになります。そのため、リレーションごとに参照先が削除されたときの扱いを先に決めておく必要があります。データベースの言葉で、この扱いには代表的な取り決めが 3 つあります。

1 つ目は、外部キーで指されている間は、参照先を削除させないという扱いです。これを RESTRICT と呼びます。たとえば、貸出は備品を指しています。もし貸出の記録がある備品を削除できてしまうと、残された貸出の記録は「何を借りたか分からない」状態になってしまいます。これでは台帳としての意味が失われてしまいます。だから貸出から指されている備品は削除できないように RESTRICT にします。貸出から指されている利用者も同じ理由で RESTRICT にします。

2 つ目は、参照先の削除は行ってもよく、外部キーの側は「値が無い」状態になって残るという扱いです。データベースでは、値が無い状態のことを NULL と呼びます。そして、この状態に置き換える扱いを SET NULL と呼びます。たとえば、備品は保管場所を指しています。オフィスの整理などで、ある保管場所(棚)を廃止することになったとします。このとき、棚を廃止したからといって、そこに置いてあった備品まで削除するわけにはいきません。備品そのものは残し、備品が持っている保管場所 ID だけを NULL にします。備品と保管場所のリレーションは、新しく購入して置き場所がまだ決まっていない備品のように、初めから NULL でも構いません。設計メモでは、このような欄に「NULL 可」と書きます。

3 つ目は、参照先が削除されると、外部キーを持つ側も一緒に削除されるという扱いです。これを CASCADE と呼びます。台帳の外の身近な例で考えてみましょう。たとえば写真のアルバムと写真の関係です。アルバムを削除すると、そのアルバムの中に入っていた写真も一緒に削除されるような仕組みが CASCADE に当たります。いまの備品台帳には、CASCADE にするリレーションはありません。

ここまで決めた内容を、設計メモに書き起こします。書き方の決まりは明快です。エンティティ 1 つに 1 つの見出しを立て、主キーと外部キーを箇条で並べます。そして外部キーには、参照先と削除の扱いを必ず添えて書きます。

設計メモとしてこのように書き残しておけば、データの構造と削除時の扱いが最初からはっきり定まり、後から作る人が迷ったり黙って決めたりすることを防げます。

この章のまとめ

この章を通して、備品台帳の設計メモの最初の形が完成しました。台帳が覚えておく 4 つのエンティティ(備品、保管場所、利用者、貸出)を拾い出し、それぞれを確実に見分けるための主キーを定めました。さらに、エンティティ同士の結びつきを外部キーで表し、相手のエンティティが削除されたときにデータをどのように保護するかという扱いもあらかじめ定めておきました。

次の章(1-3「プロパティと型」)は、それぞれのエンティティが何を覚えるか(名前、種類、日付など)と、その形を決めていきます。設計メモに具体的な項目の定義を書き足し、データ設計の作業をさらに一歩先へと進めていきましょう。