Navicatブログ

プライマリキーの選択 - パート1 2022年8月12日 Robert Gravelle

ナチュラルキー対サロゲートキー

データベース設計者として直面する最初の決定事項の 1 つは、テーブルで使用するプライマリキー(PK)の種類です。データベース管理者、開発者、テスターなど、日常的にデータベースを扱っている人に尋ねると、無数の意見や正当な理由が得られるでしょう。答えを導き出すための障害をさらに複雑にしているのは、万能なソリューションがないことです。それを念頭に置いて、このシリーズでは、様々な種類のPKに賛成する理由と反対する理由の両方を示します。それら全てのアイデアのどこかに、あなたの組織のニーズのために使用するのに最適なタイプのPKへと導くいくつかのアイデアがあるでしょう。この最初の記事では、PKの2つの基本的なタイプであるナチュラルキーとサロゲートキーを比較します。その後、データベースの自動インクリメント機能を使用するかどうか、およびどのデータ型(複数存在する場合)が最適なPKになるかについて説明します。

ナチュラルキー(自然キー)

ナチュラルキーは、テーブル内のレコードを一意に識別する、テーブルに既に存在する1つ以上の列(例えば、データモデル内のエンティティの属性)で構成されるキーです。これらの列はエンティティの属性であるため、本質的にビジネス上の意味を持ちます。以下はNavicat Premium 16のテーブルデザイナーでのナチュラルキーを持つテーブルの例です。プライマリキーは、Key列のキーアイコンで簡単に識別できます。

natural_key (110K)

データを見ると、productCodeにビジネス上の意味があることがわかります:

productCode (202K)

サロゲートキー(代理キー)

サロゲートキー(または合成キー、疑似キー、エンティティ識別子、ファクトレスキー、技術キーなど)は、テーブルのレコードを一意に識別するために使用される、ビジネス上の意味を持たないシステム生成(GUID、シーケンス、一意の識別子など)の値です。そのキー自体は、同様に、1つまたは複数の列(つまり、複合キー)で構成できます。同じデータベースのテーブルにサロゲートキーがあり、customerNumber列がそのPKとして定義されています。

surrogate_key (133K)

自動インクリメントではありませんが、顧客エンティティとは無関係の数値フィールドです:

customerNumber (163K)

決定する

では、一方のテーブルではナチュラルキーを使用し、もう一方のテーブルではサロゲートキーを使用するのはなぜでしょうか?

製品が、ある種の一意の在庫番号を持つことは非常に一般的であり、これが理想的なPKになります。数値キーを追加すると、単にディスク領域が無駄になり、ほぼ確実に、検索用にproductCode列に追加のインデックスが必要になります。一方、顧客は通常、一意の識別子を持っていません。データベースで個人を一意に識別しなければならなかった人の立場で言えば、そのためには驚くほど長い列のリストが必要です。したがって、通常は、テーブル内の全ての列にインデックスを付ける数値のサロゲートキーを割り当てる方がはるかに簡単です。

ナチュラルキー対サロゲートキーのまとめ

プライマリキーの選択に関するこの最初の記事では、ナチュラルプライマリキーとサロゲートプライマリキーについて説明し、一方よりももう一方を選択する理由を検討しました。最初に ナチュラルキーとサロゲートキーのどちらを使用するかを決定することが重要です。それは、特にサロゲートキーの場合に、どちらを選択するかがフォローアップの質問の一部に回答するのにも役立つためです。

Navicat 16を試用したい場合は、こちらから14日間のトライアル版をダウンロードできます。

ブログのアーカイブ
シェア