しがないOLのはじめての「Microsoft Access」 ~テーブル構成を考える編~

こんにちは。胃弱なクニ吉です。

前回に引き続き、MicrosoftのAccessについて書きます。

今回は、早速テーブル作成・・・と行きたいところですが、その前にどういう構成でテーブルを作るかを考える必要があります。 これは前回書いたように一番重要なところで、アプリケーションの使い勝手を左右すると考えています。 私は設計を勉強したわけでもなく、とりあえず手を動かしてやってみました。 しかし、考えてテーブルを設定したつもりでも、ちゃんと作ってみないといいのか悪いのかが分からず、 フォームまで作った後に設定し直したりと結構大変でした^^ テーブル同士を紐づけたり(リレーション設定)、フォームを作ったり、データを入れてしまうと 直すのがほんっとめんどくさいです。(手戻り作業は大抵面倒なものですけど。。。)

今回は私がどのように設定したかをお伝えして、テーブル構成のヒントになればいいなと思います。

必要な情報を考え、書き出す

では、まず自分が管理している(したい)情報を書き出しましょう。 どういった情報が必要なのかは自分を含む全利用者の視点で検討する必要があります。 アプリケーション全体だとボリュームが大きいですし、かといって何もないのは分かりづらいので、 今回は「取引先情報テーブル」を作成することをゴールとします。

ここで、前提としてどういう条件で使用するのかを整理します。

◆前提条件

  • 管理範囲:クニ吉が管理している3セクションの取引先情報 ※当時は営業部、マーケ、購買の3つ
  • 管理する目的:取引先コードの管理/閲覧、書類送付や各種問合せのための企業および担当者情報の管理/閲覧
  • データ入力者:クニ吉のみ(でも将来的には他の人が使う可能性あり?)
  • データ閲覧者:主に営業、経理、クニ吉
  • 抽出したいレポート:取引先コード一覧、担当者情報一覧
  • その他:クニ吉は複数部署の事務管理をしているが、管理が他部署に移る可能性がある。

このように前提条件を書き出すことによって、想定していなかった項目が洗い出される場合があります。 管理項目の漏れをなくすのに役立ちますので必ず行ってください。

私は上記前提をもとに以下のように書き出しました。

  1. 取引先コード ※書類番号として使用するために設定
  2. 管理部署   ※データ抽出や事務管理が他部署になった時のデータ移行を容易にするために設定
  3. 会社名
  4. 会社名フリガナ
  5. 住所
  6. 部署名
  7. 役職
  8. 担当者名
  9. 担当者名フリガナ
  10. メールアドレス
  11. 電話番号
  12. FAX番号
  13. 備考

書き出した情報をどう構成するかを考える

ここで私が考えたのが、「どう構成したら一番入力回数が少なく済むか?」ということでした。 本来であれば、取引先情報として①取引先コード~⑬備考までは同じテーブルでも問題はないのかもしれません。 しかし、前回の「Accessってなに?編」でお伝えしたように、Accessの利点であり、そもそもこのアプリケーションを作成する目的の ひとつとして「同じデータを入力する手間が省ける(=作業時間の短縮)」というのがありました。 会社名はもちろんのこと、”同じ部署で関係者が何人もいる”というのはざらでしたので、私はあえて顧客情報のテーブルをいくつかに分けることにしました。社内のエンジニアに「使い勝手はもちろん、のちのちの修正や機能追加の可能性、データ移行などを考えると、ひとつのテーブルをあまり大きくしない方がいい」というアドバイスがあったのも理由のひとつです。

◆テーブル構成案①

この4つのテーブルに分けた理由は以下の通りです。

  • 会社情報は、部署情報に比べ取引先新規登録または社名変更がない限り更新しないため、①会社情報と②部署情報を分割
  • 担当者情報に比べ部署情報の更新頻度は少ないため、②部署情報と③担当者情報を分割
  • 同じ会社でも本社、支社など住所が複数存在する場合があるため、住所は②部署情報に分類(同じ部署で住所違うことはないだろうと‥)
  • ④管理部署は、社内の部署名変更や新しい管理部署が加わらない限り更新しないため、①~③のテーブルから分割

同じ部署で住所が違うことはないと思ったので、住所情報は②部署情報テーブルと一緒にしたわけですが、 今思えば、別部署でも同じ住所だったりするから、下図のように事業所テーブルを作成しておけばよかったんじゃ?って思ったり σ(^_^ 同じビルでも階数違ったりするけど。。。

◆テーブル構成案②

とりあえず私は構成案①で作りました。 今のところ入力は以前に比べ楽になりましたし、②の構成の方がよかったかなーと後から思いつつも①の構成でも特に不都合はありません。

これはざっくり情報を分割しただけなので、実際にテーブル作成する際にはもう少し項目が増えたり、テーブル内で項目を分けたりします。 とりあえず今の段階ではこれでOK 次回はテーブル作成について書きたいと思います。

ということで以下次号!!(´ゝ∀・`)ノシ