キーの定義
前回（第12回「データの登録を行うINSERT文」）は、「CardInfo」という名前の新しいテーブルを作成し、データの登録を実行しました。今回はこのテーブルに「プライマリキー（主キー）」の定義を行います。
主キーの説明は、第6回の「SELECT文の応用」で、JOINの話の中で説明しましたが、覚えていますか？ 主キーとは、テーブルの中に保存されているデータのある1行を識別するために必要な情報です。
例えば、Customersテーブルに保存されている顧客情報の特定の1顧客を識別するためには、CustomerIDを指定すればよいので、CustomerIDは主キーとして定義することが可能です。
テーブルによっては、ある1つのフィールドのみでは特定の1行を識別できないこともあります。例えば、Order Detailsテーブルに保存されている受注明細の特定の1行を識別しようとすると、OrderIDとProductIDが必要です。このような場合には、OrderIDとProductIDの組み合わせが、Order Detailsテーブルの主キーであると定義することが可能です。
SQL Enterprise Managerのテーブルリストの中から、それぞれのテーブルをダブルクリックしてプロパティを表示させると、上記の画面1、画面2のように表示されます。「列」リストの中で、一番左に表示されている「キー」列にかぎのアイコンが表示されている列が、主キーとして定義されている列です。
では、前回使用したCardInfoテーブルに、主キーの定義をしてみましょう。
CardInfoテーブルでは、「CardID」がカード情報を特定するためのキーとなりますので、CardID列をCardInfoテーブルの主キーとして定義したいと思います。
では、SQL Server Enterprise Managerのテーブルリストから、CardInfoテーブルを右クリックして、「テーブルのデザイン」ウィンドウを表示させましょう。
CardID列を選択して、ウィンドウのタイトルバー下に並んでいるアイコンの中から、かぎのアイコンをクリックします。次の図のように、列名の左にかぎのアイコンが表示されましたか？
では次に、CustomerID列を選択して、もう一度、かぎのアイコンをクリックしてみましょう。今度は、CardID列のかぎのアイコンが消え、CustomerID列の左側に移るのが確認できましたか？ これは、テーブル1つにつき主キーは1つだけ、定義できるからです。
もし複数の列にわたる主キーを定義したければ、複数の列を選択してかぎのアイコンをクリックすればOKです。複数の列を選択するには、SHIFTキーかCTRLキーを押しながら列をクリックすればよいですね。
さて、CardInfoテーブルにはCardIDを主キーとして定義すればよいので、もう一度CardID列を選択してかぎのアイコンをクリックしましょう。選択が解除されたら、もう一度かぎのアイコンをクリックして、CardIDの列の左だけにかぎのアイコンが表示されているか確認します。
この状態では、まだ、RDBMS上に定義の変更は反映されていません。反映させるために、左上のディスクのアイコンをクリックしましょう。特に「変更が反映されました」などのメッセージは表示されませんので、本当に定義がされたか否かを確認するためには、一度ウィンドウを閉じて再度表示させるか、テーブルのプロパティを表示させます。
主キーの特性
SQL Serverの中で主キーがどのように定義されているかを確認しながら、主キーの特性について説明しましょう。
先ほどのテーブルのデザイン画面で、変更を反映させるディスクのアイコンの右隣にあるアイコンをクリックすると、「プロパティ」ウィンドウが表示されるので、「インデックス/キー」タブを選択します。
インデックスについては、また回を改めて説明しますが、SQL Serverでは主キーとインデックスが切り離せない関係になっているため、次の点だけは押さえておきましょう。
インデックスとは、本でいうところの索引に相当します（英語ではそのものですね）。本の最後に添付されていて、キーワードがあいうえお順に並べられているページです。キーワードの横にはページ番号が記されているので、ある特定のキーワードを調べたければ、すぐにたどり着くことが可能ですね。
RDBMSにも同様な仕組みが用意されており、特定のカラムや複数のカラムの検索効率を向上させるために、インデックスを定義することが可能です。特にレコード数が多いテーブルに対して効果を発揮します。
インデックスには、パフォーマンスの向上、という使命のほかに、UNIQUE制約の制御、というもう1つの大きな使命があります。これは、インデックスを作成する際に定義することが可能で、フィールドに保存される値が唯一かどうかを制御することが可能です。例えば、CardID列は、絶対に同じCardIDが保存されないことを保証する必要があるとします。この場合は、CardID列にインデックスを作成し、「UNIQUE制約」を定義する必要があります。
さて、先ほどの「インデックス/キー」タブに戻りましょう。「選択したインデックス」欄には「PK_CardInfo」と表示されていますね。これは、PK（プライマリキー）_CardInfoというインデックスが定義されていることを表示しています。これは、SQL Serverが主キーを定義した際に、自動的に作成したインデックスです。インデックスの名前は、デフォルトでPK_（テーブル名）となります。
そのほかの情報を確認してみると、まず、対象の列は「CardID」列になっていますね。あと、左側中央にグレイアウトされていますが、「UNIQUEの作成」というグループボックスがあり、チェックされているのも確認できます。また、そのオプションで「制約」が選択されていますね。
このように、主キーを定義すると、その列に対してインデックスが作成され、UNIQUE制約が定義されることが分かったでしょうか。
SQLでの主キーの追加
先ほど、SQL Server Enterprise Managerで作成した主キーをSQLで作成するためには、次のようなALTER文を実行します。
【例1】
ALTER TABLE CardInfo ADD CONSTRAINT PK_CardInfo PRIMARY KEY NONCLUSTERED ( CardID ) ON [PRIMARY]
主キーの定義はテーブルに対しての定義になるので、ALTER TABLE文を使用します。TABLE句の後にはテーブル名を指定して、「ADD CONSTRAINT」とします。CONSTRAINTとは「制約」の意味で、先ほど説明した「制約」のラジオボックスにあたります。続いて、主キーの名前を記述し、タイプとして「PRIMARY KEY NONCLUSTERED」を指定します。これは、PRIMARY KEYで「主キー」であることを宣言し、さらに「NONCLUSTERED」であることを指定しています。インデックスにはCLUSTEREDとNONCLUSTEREDの2つのタイプがありますが、この違いについてはまた回を改めて説明します。
次に、（ ）でくくられた中に、対象となる列名を、カンマ区切りで指定します。最後にON [PRIMARY]としている個所は、インデックスファイルの指定ですが、デフォルトでこのようになるとここでは理解してください。これも回を改めて説明します。
今回のまとめ
今回は、主キーの作成について解説しました。次回は、データの更新（UPDATE）について解説していきます
- SQL Serverで「デッドロック」を回避する
- トランザクションの一貫性を保証するロック
- トランザクションを用いて注文登録をする
- トランザクションでデータの不整合を防ぐ
- テーブルで複数の処理を実行させるトリガー
- ユーザー定義関数を作成するストアドファンクション
- ストアドプロシージャによる繰り返し処理
- 条件分岐のあるストアドプロシージャ
- ストアドプロシージャの作成
- システム・ストアドプロシージャを用いたロールの詳細設定
- ロールを利用したグループ単位での権限設定
- SQL Serverのオブジェクトに権限を設定する
- Enterprise Managerによるビューの作成
- 作成したSELECT文をDBに登録する「ビュー」
- データの更新と主キーの重要性
- テーブル中のデータ識別に必要な主キーを定義する
- データの登録を行うINSERT文
- CREATE文をさらに使いこなそう
- CREATE文でテーブルを作成する
- SELECT文を統合する「UNION」
- サブクエリーの応用「相関サブクエリー」
- SELECT文の結果を抽出条件に使う
- テーブル結合のバリエーションを増やす
- テーブル結合の仕組みを理解する
- 異なるテーブル同士を結合する「JOIN」句
- 集計を行う「GROUP BY」句
- SELECT文で並べ替えを行うには？
- SQLの基礎 「SELECT」文を覚えよう
Copyright © ITmedia, Inc. All Rights Reserved.