さて、前提条件が揃ったのでさっそく実践にとりかかるとしましょう。とりあえず移行手順を考えてみましょう。
1．台帳を正規化しながらテーブルを設計します。
2．フォームやレポートに必要と思われるクエリを作成します。
3．入力及び閲覧用フォームを作成します。
4．指定された集計レポートを作成します。
5．フォームやレポートを開くマクロを作成します。
こんなとこでしょうか。まぁ問題が発生したらその度に対応してきましょう。
では今回は「台帳を正規化しながらテーブルを設計」にチャレンジしましょう。正規化が苦手な人、分かんない人はとりあえず1つのデータの固まり（今回は台帳）の中に日付や数値以外で重複する項目を探し、見つかったらそいつは正規化候補だと思って列挙してみてください。それから列挙したものを同一のグループにできないか考えてみましょう（例えば商品名と単価とか）。そうやってグループ分けしてできたものがテーブルになります。…我ながらなんて安直な説明でしょうか、でも個人的には最初はそんなもんでOKだと思います。こーゆーのはやってくうちになんとやらです。
商品マスター（物理名：Goods）
| 論理名 | 物理名 | 型 | 主キー | 外部キー |
|---|---|---|---|---|
| 商品ID | GoodsId | オートナンバー | ◯ | |
| 商品名 | GoodsName | テキスト | ||
| 単価 | Price | 通貨 | ||
| 商品カテゴリーID | GoodsCategoriesId | 数値 | ◯ | |
| メーカーID | MakersId | 数値 | ◯ |
商品カテゴリーマスター（物理名：GoodsCategories）
| 論理名 | 物理名 | 型 | 主キー | 外部キー |
|---|---|---|---|---|
| 商品カテゴリ－ID | GoodsCategoriesId | オートナンバー | ◯ | |
| カテゴリー名 | CategoryName | テキスト |
メーカーマスター（物理名：Makers）
| 論理名 | 物理名 | 型 | 主キー | 外部キー |
|---|---|---|---|---|
| メーカーID | MakersId | オートナンバー | ◯ | |
| メーカー名 | MakerName | テキスト | ||
| 電話番号 | Tell | テキスト | ||
| FAX番号 | Fax | テキスト |
売上データ（物理名：Sales）
| 論理名 | 物理名 | 型 | 主キー | 外部キー |
|---|---|---|---|---|
| 売上ID | SalesId | オートナンバー | ◯ | |
| 売上日 | SaleDate | 日付/時刻 | ||
| 商品ID | GoodsId | 数値 | ◯ | |
| 数量 | Qty | 数値 |
在庫データ（物理名：Stocks）
| 論理名 | 物理名 | 型 | 主キー | 外部キー |
|---|---|---|---|---|
| 在庫ID | StocksId | オートナンバー | ◯ | |
| 商品ID | GoodsId | 数値 | ◯ | |
| 数量 | Qty | 数値 |
いきりなりまじめな設計するなって言われそうですがこんな感じでどうでしょう？。せっかくなんで商品カテゴリーも作っちゃいました。これで商品カテゴリーマスターと商品マスター、商品マスターと売上データ、商品マスターと在庫データ、メーカーマスターと商品マスターがそれぞれ1対多になるのでリレーションシップも設定しちゃいます（マスターとデータ（トラン）の違いやリレーションシップはさすがに基礎過ぎるので省略します）。売上データや在庫データの仕組みとか、もっとしっかり考えてもいいんだけどやりすぎちゃうと趣旨が変わっちゃうのでこのへんにしときます。
あと、日付/時刻型について「VBAを使う場合、エラーの温床となる可能性があるのでテキスト型にした方が良い」とよく言われてますが個人で開発する分には日付/時刻型で大丈夫なんじゃないの？ってのが自分の感想です。まぁ今回はVBA使わないので遠慮なく日付/時刻型です。
リレーションシップの図
では、今日はここまで。
