出典
仕事には「流れ」があります。
「在庫」も、突発的に数字が現われるのではなくて、最初に倉庫に100個あって、昨日4個売れて96個になって、今日8個売れて88個になって・・・という具合に、88個という数字をはじき出すためにいくつかのプロセスを経過しているわけですよね。
他のコーナーでもくどくどお話してますので、「もうわかってるわい」という方も多いかもわからないですが・・・データベースと表計算ソフトを使い分ける上で最も重要なポイントのひとつは、「処理の履歴が必要かどうか」ということなのです。
つまり、「とにかく88個という現在の在庫だけが残ってればいいのか」「100引く4個引く8個、そんで88個」という具合に、過程を残すのか、その辺のところをしっかり考えていくのです。
まあ、「商品の種類が5万種類あるんです」なんて場合は別ですけど・・・前者の考え方ならはっきりいってデータベース使う必要性はほとんど見られないです。表計算ソフト使ったほうが絶対便利。っていうか、今までやってきたことが前者の考え方に準じた方法なわけですが、超めんどくさいですよね。この考え方で何もかもデータベース作ろうとすると、AccessだろうがOracleだろうがSQLServerだろうがInfomixだろうが、どれも使いにくくて不便に違いない。2次元的な考え方でフラットにデータ全体を見渡して自由に操作することができる表計算ソフト使って在庫管理した方が楽です。
後者の考え方は、いわゆる「トランザクション処理」と呼ばれる考え方になります。
それに対して、前者の考え方は「マスター処理」に近い考え方になります。
どこがどう違うのか、どうすればいいのか・・・これをしっかり理解することが、リレーショナルデータベースの基本構造を理解することにつながります。
［商品テーブル］とか［在庫テーブル］は、基本的に［商品］単位で物事を考えますよね。
テーブルの中の、一番小さな情報の単位は「商品」です。なので、各商品にダブらないように［商品番号］をつけて、どんな名前の商品でも検索したり分類したり並べ替えたりしやすいようにしてます。こういう構造のテーブルをあえて「マスターテーブル」と呼んだりします。
ふつうのテーブルですけどね。まあ、気持ちの問題です。情報の出し入れの単位が「商品」ということです。
それに対して、「売上テーブル」はどうでしょう。情報の最小単位は？
「売上一回に対して、１レコード」ですよね。つまり、１処理で１レコード。
こういう仕組みのテーブルを「トランザクションテーブル」と言います。
作り方が違うとか設定が違うとかそういうことじゃないですよ。テーブルとしては同じです。
ただ、中に入ってくるデータの「最小単位」が違うわけです。
じゃ、在庫は？マスターっぽく考えればいい？トランザクションっぽく考える？？？
それによって、「マスター系のテーブルに在庫数を持つべきか、トランザクション系のテーブルに持つべきか」決まります。
在庫も、「とりあえず今ある数」だけ知りたいのであれば、「商品」ごとにわかればよいですね。なので、［商品テーブル］みたいな「商品ごと」のテーブルに［在庫数］見たいなフィールドを持たせればオッケーのはず。マスターっぽく考えてよいのかな・・・。と思って[商品テーブル]に在庫数の項目を作ったんですけど、なんか妙にめんどくさかったですよね。
データベースでは、［商品テーブル］みたいなテーブルの他に、「1処理ごとにデータがたまっていくテーブル」を作ることがあります。おんなじテーブルですけど、要するに［売上テーブル］みたいな感じの、「売上1回が1レコード」的テーブルですね。こういうのを「トランザクションテーブル」なんて呼んだりします。
顧客名とか住所とか、商品名とか、単価とか・・・1処理ごとに内容が変わったりするもんじゃないですよね。こういうのは。。。でも、在庫数って、どうなんでしょう。
確かに情報の単位としては「1商品に、1在庫数」ですけども、数値が減ったり増えたりするのは、1処理ごと、ですよね。
なんか売れると、在庫は減ります。売れないものもあって、減らないものもあります。
それに・・・あとあと、「入庫」したときのこととか、「返品」されたものの扱いはどうするのか、とか、いろいろ考えるとなると、［在庫テーブル］の［在庫数］を引いたり足したりする今のやり方では、かなり厳しいんじゃないでしょうか・・・。
もちろん、間違いじゃないんですよ。できますよね。しっかり仕組みを作っておけば、これでも十分在庫数を把握することは可能だと思います。
ここまでがんばってきてなんなんですけど、とりあえず「大変だ」ってことで、もう一方の方法を試してみましょう。
つまり、在庫数を「トランザクション」っぽくとらえてみようというわけです。
■「［売上明細テーブル］の［売上数］の合計を引き算して現在庫数を算出する」
一呼吸おいてくださいね。
では、ふたつめの考え方・・・「［売上明細テーブル］の［売上数］の合計を引き算して現在庫数を算出する」をやってみましょう。
今までのことはちょっと忘れて、新たな気持ちで取り組んでみてください。
在庫テーブルには、↑「期初在庫」というフィールドを持ちます。
半年に1回とか、1年に1回とか、倉庫の中の在庫数の確認を、人の手によって行い、実際のデータベース内の数値と合わせて、本当の在庫数を入力しておくわけですね。。。で、ここから新たな気持ちで受注を受け付け、在庫数を算出していくわけです。
引き算するっていったって、基準になる値がなきゃ、引けませんもんね。
さて、で、どうやって「現在庫」を知るかというと・・・。
こういうクエリを作ります。↑
集計クエリ（Σ）にして、売上数を合計するのです。
で、右端の方で、期初在庫から売上数を引き算する式を作ります。名前は式1とか適当につきますから、そのままでいいでしょう。
いやだったら変えてください。
出ます？↑
要するに、「期初」からの売上数をぜーんぶ集計して、引き算するイメージになるわけですね。名前をつけて保存しておいて、あとでいろいろ使おうと言うわけです。んでもって、式1が、最新の在庫情報になります。やっぱ式1じゃいやですか？ホホホそりゃそうですよね。適当に変えてください。
あたしはこのまんまでいいや。
でも、このクエリ、よく見ると、「売上のあった商品」しか出てないですよね。
これはですねぇ。ふたつのテーブルの結びつき方によるものです。
ふつうはこのままでいいかもしれないですけど、1回も売れてない商品だって、在庫数わかんないと困りますよね。
その場合は、この結合線をダブルクリックして、結合の仕方を変えます。
・・とりあえず全部の商品の情報は、出そう？
でもー、なんで、在庫数（式1）がからっぽの商品があるんでしょうねぇ・・・。↑
これはですね。
式1って、［期初在庫］-［売上数（の合計）］っていう計算によって出ますよね。
68097-15=68082 ですけれど、
220-0=220
のはずなのに・・・。
と、ここんとこが思わぬ落とし穴。
わたしたちが目で見て、「空欄」になってるところ・・・ゼロではないのです。「空欄」なのです。もっと正確にいうと、売上明細テーブルに存在しないデータなわけで、「グフの売上数の合計」はこの世に実在しないわけです。
220-実在しない=実在しない
になります。もー！コンピュータってばかですよねーほんとにバカです。大バカです。
計算式のどこかに「実在しない値」とか「空欄」とかが入ってると、答えは出ません。エラーにもならない。計算式自体が機能しないのです。
じゃどうすれば・・・。
なんらかの形で、「空欄はゼロよ」と教えてやらないといけません。
で、こんな感じに書き換えます。
売上数の合計: IIf(IsNull([売上数]),0,[売上数])
ちょっとややっこしいですが、IIF関数とIsNull関数をうまく組み合わせて、「Nullだったら0、そうじゃなかったら［売上数］を出せ」と命令しましょう。
IIF関数、IsNull関数、あと、Nullってなに？ってとこに関しては、ヘルプで確認してください。
あと、これは超豆知識ですけども、クエリの中で式を作るとき、基にしているテーブル内に実在するフィールド名とダブらないようにしましょう。
今回は［売上数の合計］という式の名前にしてみました。これならダブらないですよね。
ありゃ？ゼロは出るようになったけど、やっぱし計算してないな・・・・。↑
実際には［売上数の合計］っていう列の名前になってるのですね。こうなると。そしたら・・・。
式を書き換えてやりましょう。多分、［売上数］じゃもうなんのことだかクエリにはわかんなくなっちゃってるんだと思いますので、［売上数の合計］という名前に書き換えてやってください。
出たかも～。↓
どうでしょう？
「在庫数」というフィールドをテーブルに持たせないで、クエリをうまく活用して在庫数を知るという「考え方」です。
くどいようですが、最終的に「在庫数」がわかればよいわけですから、「マスター的考え方」でも「トランザクションっぽい考え方」でも、どっちでもよいのです。
ただ、もし、AccessにしてもOracleにしてもSQLServerにしても「いわゆるデータベース」と呼ばれるものを利用して在庫数を得ようとするなら、「マスター的かトランザクション的か、ウチの会社の在庫処理の場合どっちの方が適しているのか」を、じっくり考えてください。
正確には、「じっくり考えるために、この辺の考え方をしっかり身につけておこう」ということです。
- どういう業務で
- どういう項目が必要で
- その項目はどのテーブルに存在すべきか
ということをじっくり考えることが、正確でわかりやすい在庫処理につながっていきます。
クエリの作り方とかVBAの書き方とかそういうこと覚えても、ここんとこちゃんと考えないと前に進めないっすよね。