メニューを考える

前回でとりあえずテーブルの設計は終了です。

次のステップは、メニューを考えます。

？？？
聞こえますよ～。


　　「　テーブル設計が終わったら、
　　　　ようやく、Access の操作じゃないの？　」


まだ。

実に簡単な作業ですが、メニューを考えてから、Accessに着手します。

理由があります。

１．Accessは複数のオブジェクトを組み合わせてシステム構築するから
２．システムはメニューを積み上げたものだから
３．メニュー（機能）とオブジェクトの関連性を可視化する為


なぜ、なぜ、原因分析って感じですが、この３つが理由です。


Accessは、「テーブル」「クエリ」「フォーム」「レポート」「マクロ」「モジュール」の６種類のオブジェクトを複数組み合わせて作り上げていきます。

それらの関係性を番号で関連付けさせて、オブジェクトとメニューの関係性を持たせます。

オブジェクトの番号で「○○のメニューに使われているクエリだ」と中身を見なくても認知できるなど、メリットが多いので、Accessに着手する前にメニューを考えるのです。

テーブル設計と新しい業務設計をした絵からメニューを考えていきます。
（前に書いたnoteの絵のリンク）

メモ帳レベル（Wordで書きますが・・・）で十分です。

メニューの設計

次に番号を付与します。
この番号は、後々 Access で実装する時に役に立ちます。

メニューに番号を付与

次に、必要な機能を追記します。

メニューに機能を追記

次に、画面の設計を考えます。……… と書きましたが、

正直、作らなくてもいいと思う。
・・・　いや、売り物、他部門に渡すものなら、作るべき。

でも、作らなくてもいいと良いと思う理由がある。

１．そもそも発注者と設計者が同一人物
２．目に見える成果物はそれ自体が仕様書
３．利用者の事情を深く理解している

この３点。

特に、２．「目に見える成果物はそれ自体が仕様書」の理由が大きい。

今回はここまで。

実は、まだまだ、Accessを触りません。

もう一つ、重要なことを考えることがあります。

それを次回の記事にして、事前準備（設計）は終了となります。

それと、実際にAccessに触れる前に、番外編として、
AccessがExcelに比べて、とっつきにくい理由をAccessの成り立ちから考えた記事（完全に自論）を書きたいと思います。


ここまで読んでいただき、ありがとうございます。
お陰様で、今日も美味しいお酒がのめそうです。