サブデータシート

 テーブルを直接操作してデータの編集を行う際に大変便利なサブデータシートについて紹介します。

サブデータシートの例

f:id:accs2014:20170816001624p:plain:right:w400

 まずは設定後の例から見てみます。
 「部署テーブル」には会社の部署の情報が記録されており「部署コード」列が主キーとなっています。ここでテーブルの左端に「+」のマークが見えますが、これをクリックすると…


f:id:accs2014:20170816001621p:plain:right:w400

 別の「社員テーブル」に記録された社員情報が表示されます。これらは編集することも出来ます。これがサブデータシートです(このような機能をサブデータシートといいますが、表示されている社員テーブルのことをサブデータシートと呼ぶ場合もあります)。


f:id:accs2014:20170816001617p:plain:right:w400

 さらに各レコードの+マークをクリックすると、それぞれ異なる社員の情報が表示されます。ここがポイントで、つまりそれぞれの部署に所属する社員だけが表示されています。
 ではなぜそうなるのかですが、もちろん事前の準備が必要です。


f:id:accs2014:20170816004730p:plain:right:w500

 社員テーブルを単独で開いてみますと、社員番号(主キー)や氏名などのほか、部署テーブルにもあった「部署コード」という列が存在します。この列があることで、各社員がどの部署に属するのかがわかるようになっています。サブデータシートを利用するにあたっては、このように両方のテーブルに共通する列を設けておくことが必要となります(正確には列名は同じでなくていいですし、全く無関係な列どうしでも設定することはできます。しかし、両方の列に共通する値が記録されていないと設定する意味がありません)。
 なお、社員テーブルにおける部署コードのような列を外部キーといいます。主キーの節(こちら)でも別の例を挙げて説明していますので確認していただきたいと思います。要するに主キーとなる列、外部キーとなる列をそれぞれ設定することによって、サブデータシートを活用する準備が整うというわけです。


サブデータシートの設定

f:id:accs2014:20170816001612p:plain:right:w600

 まずは最初に紹介した2つのテーブルでのサブデータシートの設定について見てみます。
 実はとても簡単です。メインのテーブルである部署テーブルをデザインビューで開き、プロパティの「サブデータシート名」で「テーブル.社員テーブル」を選択するだけです。本来はその下にある「リンク子フィールド」「リンク親フィールド」というプロパティも設定する必要がありますが、それぞれのテーブルの列の設定が適切であれば自動的に設定されます。これだけで冒頭のような操作が実現できます。
 補足ですが「リンク子フィールド」「リンク親フィールド」は、サブのテーブルとメインのテーブルを、それぞれどの列で結びつけるのかを設定するためものです。手動で任意の列どうしを結び付けることも出来ますがここでは省略します。


f:id:accs2014:20170816001621p:plain:right:w400

 データシートビューで操作している様子です(上記画像の再掲)。
 サブデータシートとして表示されている社員テーブルには、部署コードは表示されないことに注意してください。


f:id:accs2014:20170816001608p:plain:right:w600

 さて、サブデータシートとして設定したテーブルに、さらにサブデータシートを設定することもできます。
 社員テーブルを開き、サブデータシート名として「受注テーブル」を選択します。この例では「受注テーブル」にも(その受注を担当する社員を表す)「社員番号」列が外部キーとして存在しており、「リンク子フィールド」「リンク親フィールド」として「社員番号」列が自動的に設定されます。


f:id:accs2014:20170816001643p:plain:right:w500

 そこで部署テーブルを開きます。
 +マークをクリックすると最初の例と同じく社員テーブルの情報が表示されますが、そのレコードの左側にも+マークが現れます。これをさらにクリックすると受注テーブルの内容(つまりその社員が担当する受注)が表示されます。
 見た目はちょっと複雑になりますが、サブデータシートを利用すればテーブル間の親子構造(この例では部署テーブル-社員テーブル-受注テーブル)をそのままテーブルの表示と編集に反映することができます。フォームでもサブフォームを用いて同じような設定はできますが、特に深い階層を設ける場合にはサブデータシートの方が設定が簡単で便利です。ただし1つのテーブルに複数のサブデータシートを設定することはできませんので、必要に応じて設定を切り替える必要があります。


操作上の注意

f:id:accs2014:20170816222442p:plain:right:w400

 さて、サブデータシートとして「社員テーブル」を設定した状態で部署テーブルを開きます。
 サブデータシートのデータは更新することができますし、レコードを削除したり新たなレコードを追加することも出来ます。この画像の例では、企画開発室に属する社員として社員番号8の新たなレコードを追加しています。
 このとき、サブデータシートである社員テーブルの部署コードは表示されていませんが、企画開発室の部署コードである「2」が自動的に入力されていることに留意が必要です。


f:id:accs2014:20170816222439p:plain:right:w400

 さて、次に総務課の社員データを開いた状態で、総務課の部署コードを1から99に変更してみます。すると…


f:id:accs2014:20170816222431p:plain:right:w400

 2つ表示されていたサブデータシートのレコードが消えてしまいます。
 ちょっとびっくりしますが、サブデータシートのレコードは削除されたのではなく、所属コードが一致しなくなった(総務課の部署コードが99になった一方で社員の所属コードは1のまま)ために表示されなくなったのです(総務課の部署コードを1に戻すと消えた2つのレコードは再度表示されます)。
 サブデータシートを設定しても、双方のテーブルの所属コードの値が常に一致するよう保たれるわけではないので、このような値の変更により不一致が生じること(どの社員がどの部署に属するのかわからない、いわば迷子状態になってしまうこと)は避けられません。この点は普通のテーブル操作と変わりはありません。

 こうした値の不一致を避けるために、リレーションシップという機能があります。主キーの値の変更を禁止したり、逆に主キーの値の変更に合わせて外部キーの値を変更するといった機能があり、迷子状態のレコードが発生することを防ぐことができます。
 下記でも少し触れていますが、別の節で詳しく解説していますのでそちらを参照してください。


リレーションシップとの関係

f:id:accs2014:20170816231645p:plain:right:w400

 さて、上記のような設定操作をしなくとも、リレーションシップにより双方の列を結びつけると、自動的にサブデータシートの設定も行われます。本来リレーションシップは双方の列の値の整合を保つための機能で、サブデータシートが設定されるのはオマケに過ぎませんが、覚えておいて損はありません。
 リレーションシップは大変重要な機能ですので、別の節(意義についてはこちら、設定についてはこちら、など)で詳しく解説しています。


まとめ

 サブデータシートを設定することにより、複数のテーブルにまたがる入力作業を簡単に進められるようになりとても便利です。
 特に作成者が自ら入力操作を行うようなデータベースの場合は、本格的なフォームを作らずともこれで十分、というケースも多いはずですのでぜひ活用していただきたいと思います。

フォーム上のサブデータシート

 ちなみにですが、フォーム上でサブデータシート付きのデータシートが表示されていることがあります。あれはサブデータシートを設定したテーブルを表示しているのではなく(メイン)フォームとサブフォームです。詳しくは次の記事をご覧ください。

www.accessdbstudy.net