【入門編】外部キー制約 – PostgreSQL

こんにちは！データベースの世界へようこそ。
普段、何気なく使っているスマホアプリやWebサイトの裏側で、データたちがどうやって「迷子」にならずに整理されているか、考えたことはありますか？

今日は、PostgreSQLにおける「外部キー制約」という、ちょっと堅苦しい名前の機能についてお話しします。難しそうに聞こえますが、実は私たちの日常生活のルールと全く同じなんですよ。

—

一言で言うと、「勝手な行動を許さないための、データの約束事」です。

想像してみてください。あなたは「注文リスト」というノートを持っています。そのノートには、「誰が何を注文したか」が書かれていますよね。でも、もし「名前」の欄に、どこにも存在しない架空の人物の名前が書かれていたらどうでしょう？

「えっ、この注文、誰の分？そもそもそんな人いないよ！」と困ってしまいますよね。

データベースの世界でも同じです。「注文テーブル」にデータを入れるとき、「その注文主は、ちゃんと『顧客リスト（親テーブル）』に登録されている人ですか？」とチェックする仕組み。これが「外部キー制約」なんです。

これがないと、データベースの中はすぐにゴミ屋敷になってしまいます。

これらを防いで、「データ同士のつながり（参照整合性）」をピシッと維持してくれるのが、この制約のすごいところなんです。

—

さて、ここからが面白いところです。もし「顧客リスト（親）」からあるお客さまのデータを削除しようとしたとき、そのお客さまの「注文データ（子）」はどうすべきでしょうか？

PostgreSQLでは、そんなときのために「親がいなくなったら、自分たちはどう動くか」というルールを決めておけます。よく使うのはこの3つです。

「親が消えるなら、僕たち注文データも一緒に消えます！」という潔いタイプ。お掃除の手間が省けるので、一番よく使われます。

「親は消えちゃったけど、注文データは残すよ。ただし、誰の注文か分からなくなるから、名前のところは空欄（NULL）にしておくね」というタイプ。

「親を消すなんてダメ！まだ注文データが残っているから、親を消そうとするなんて許しません！」と、そもそも削除自体をブロックするタイプ。一番安全志向ですね。

—

初心者のうちは、「制約なんて設定すると、データを消すときにエラーが出て面倒だなあ」と感じるかもしれません。でも、この「面倒」こそが、あなたのデータを守る防波堤なんです。

後になって「あれ、このデータどこから来たんだっけ？」とパニックにならないために。テーブルを作るときは、ぜひ「外部キー」という名の「絆」を、テーブルとテーブルの間に結んであげてくださいね。

皆さんのデータベース設計が、今日も美しく整ったものになりますように！
それでは、また次回の記事でお会いしましょう。質問があればいつでもコメント欄で教えてくださいね！