|
一方でデータベースの横の項目数は上記ソフト画面のように画面内に収まりきる程度の数です（上記データ例なら項目数は9個）。
:※ 説明の都合上、読者がイメージしやすいようにスーパーマーケットで説明しましたが。果たして現実のスーパーマーケットで在庫管理ソフトが用いられているか否かは知りません。あくまで説明のための仮イメージです。
:もしスーパーマーケット業界が在庫管理ソフトを使わない場合、製造業の在庫管理などに置き換えて考えてください。少なくとも一定規模以上の製造業なら資材部や購買部などの名称の部門が、倉庫で在庫管理をしていますので。
もし、ゲームで「攻撃力配列」のようなものを作るとしたら、これは上の在庫管理的データベースでは「品名配列」{"オイシー牛乳","ごくごくオレンジ", ・・・後略 }を作るようなものであり、もしその商店が1000個の商品を扱っているなら、品名配列も要素数1000という巨大配列になってしまいます。
なので、攻撃力配列を作っても、けっして無駄にはなりません。
}}
==== コラム: 「棚卸し」という概念 ====
「棚卸し」（たなおろし）という概念は、ビジネスマンの常識ですので、知っておいてください。
ゲーム開発では「棚卸し」という在庫管理の概念は直接は使わないですが、しかし在庫管理の手法はまた品質管理の見本でもあります。なので、在庫管理ソフトの仕組みの勉強は、めちゃくちゃデータベース設計の参考になります。
{{コラム|棚卸しと在庫管理ソフトとデータベース|
在庫管理ソフトを用いていても、そのソフトに保存されている在庫量の値が本当に自社の在庫量を反映しているかどうか、「棚卸し」（たなおろし）が定期的に必要です。（帳簿や在庫管理ソフトなどにある在庫管理データを、データが本当に正しいか否かを現場で確認することを「棚卸し」（たなおろし）と言います。）
一般に、棚卸し中は、その店舗は販売中止しています。
なぜなら、自社の在庫を数えている最中に、商品が売れたり入荷したりして在庫の数が変動してしまうと、混乱するからです。
だから棚卸しが実施される日程については原則的に、外部に対する休業日などに行われます（自社内では営業中で給料が払われてる）。
だから多くの企業では、よく期末（盆休みの前と冬休みの前）または期首（「きしゅ」。盆休み明けおよび冬休み明け）あたりに棚卸しをします。
棚卸し対象の製品は、自社で保管している製品すべてなので、なので多くの商品のある会社では1人では数え切れず、よって倉庫内などの保管コーナーごとに分担して数えます。
たとえば製造業の棚卸しなら、電気部品と非電気部品とは別々の場所においてあるので、電気部品を棚卸しで数える社員Aと、非電気部品を棚卸しで数える社員Bとで、分担する、・・・というような方法です。
どこの企業でも、新人は棚卸しに借り出されます。在庫管理の勉強です。
在庫管理ソフト上の在庫量と品名、型式、種類（どこの置き場に保管してあるかを判断するのに必要）、 などを印刷でプリントアウトして、
そのプリントアウト在庫管理データ紙を持ち歩きながら、実際に現物の保管場所の前に行って、在庫量を数えるて、確認するのです。
もし在庫量がデータと実物で違ければ、赤ペンなどでプリントアウト在庫管理データ紙に正しい数量を書き込んだあと、
在庫管理部署の管理者に報告します。（そしてその管理者が、適宜、パソコン上の在庫データを修正する。）
ゲームのような完全なソフトウェア上の「攻撃力」や「守備力」などの内部データには実物はありませんが、
棚卸しのように分担して確認しやすいよう、うまくコード設計も工夫できたら望ましいでしょう。
}}
==== C言語の都合 ====
製造業の図面などの「部品表」の番号でも、同じようなテクニックが使われます。設計変更により過去の廃止になった部品に当てられていた番号は、消すのではなく、新規の番号を確保して、その新規番号に代替の新部品を割り当てるというテクニックです。
また、「登録IDを最整列して並び替える」なんてことは、一切、しません。そもそも、在庫ソフトにそのような機能も原則、ありません。
もし在庫番号の並び替えをすると、「本当に並び替え後の番号が合っているか？」などのチェックの手間が生じます。
}}
}}
==== ネット関連データベースの監視業務 ====
{{コラム|投稿の監視もwebサイト管理者の仕事|
上記のように、ハッカーなどがテキスト投稿にプログラムを埋め込むハッキングがあります。
だからwebサイトのサーバー管理者の仕事のひとつとして、
投稿テキストなどにプログラム異常を起こすハッキング的プログラムが組み込まれてないかどうかをチェックするのも仕事です。
チェック方法は単純で、最終的には「実際に人間のサーバ管理者が投稿テキストを読む」のが確実です。サイト出力された情報だけを読むのではなく、投稿が入力された時点での、まだサイト出力されてない段階でのテキストごと、証拠として保管しておくのが確実です。
このほか、どのユーザーがサイト上のどのボタンを押したかとかのアクセスログなどの情報も、ログファイルとして保管します。
もちろん、投稿が大量な場合や、管理者が忙しい時期には、すぐには読めません。だからもし不審な動作が見つかったとき等に、ハッカーなどを特定するためにログを残しているのです。
たとえば小規模なテキスト投稿サイトなどだと、たとえば違法な書き込みがされても数時間後に書き込み消去されてたりして「この投稿は削除されました。」などの文言に置き換えられていたりして、
つまり、実際にサイト運営スタッフまたはサーバ管理者が投稿テキストを読んだりしている様子が伺えます。
あるいは、こういうチェック仕事が面倒な場合、そもそもコメント投稿の機能自体をサイトに搭載しないのも手です。
匿名ユーザーからのコメント禁止のサイトもよくあります。
「お問い合わせはメールのみ」にして、メールアドレスを相手先に知らせられない人からの連絡を一切受けないのも手です。
もっとも、悪徳webサイトで、このメール問い合わせを悪用して、サイト閲覧者からの個人情報を得ようとする悪徳webサイトもあるので、そういうサイトにダマされないようにしましょう。
信頼できないサイトに、メールを送ってはいけません。
}}
==== 配列の次元の設計では仕様書の印刷しやすさを考えて ====
だから4次元目とか5次元目が100個とかあるデータ構造は、おそらく論外でしょう。そうではなく、紙の仕様書などで印刷可能なデータベース構造を考えるべきです。
:（※ 以降、雑学なので、興味なければ、コラム末尾までは、読み飛ばしてよい.）
応用数学でも似たような問題があって、高校の数学3Cなどで習う「行列」を一般の次元に拡張した理論として「テンソル」というものがあり、理論物理（相対性理論など）の一部の分野で応用があるのですが、しかしどうやって教科書などの紙に記述すればいいかの難点があるので機械工学や電気工学などの応用の場ではテンソルはあまり使われていないのが実情です。あるいは弾性体力学の分野などで名前だけ「テンソル」という数値の集合が使われていても、実態は（数学・物理学的な意味での）「テンソル」ではなく（縦×横という2次元である）行列の形式での表現に置き換えている工学書もよくあります。
}}
ただし、これはあくまでRPGの場合の議論であり、けっして『信長の野望』のようなシミュレーションゲームには当てはまらない。本セクションではもうシミュレーションゲームのデータベースについては深入りしない。
==== 在庫管理ソフトの運用 ====
<!-- テンプレート内ではwikitableが使えないので、 テンプレート:コラム のソースを直接記述で代用 -->
{| style="border:2px solid #aabbdd; width:80%; border-radius: 4px;" cellspacing=0
|style="background: #aabbdd; font-size: 115%; padding: 0.2em 0.2em 0.3em;"|在庫管理ソフトの運用のコツ
|-
|style="padding: 0.5em; background: #fafafc;"|
ゲームと関係ない余談ですが、在庫管理ソフトに入力する品名データは、別に正式名称である必要はありません。（上述のスーパー棚卸しの例では「オイシー牛乳」とか品名を書きましたが、説明の簡略化のためのウソです。）
たとえば製造業の在庫管理ソフト上のデータなら、
:「電気ｹｰﾌﾞﾙ 9mm直径」
のような品名で入力されている部品が、その電気ケーブルメーカーでは実は品名が「ナナビシニューダイア電気ケーブル」とか長い名前だったりします。
しかし、そんなの利用者側には関係ありません。
:「電気ケーブル 9mm直径、ﾅﾅﾋﾞｼ電気、型式: SFR4-BJ8F」
のような情報さえ分かれば、在庫管理では棚卸しや（倉庫から製造現場への）出荷などの際に資材部社員が部品特定のために確認できるので充分だからです。 （この他、実際にはID番号と末尾「コメント」などの項目があるが、説明の簡略のために本コラムでは表記を省略。実際には下記のような感じ。）
<!-- 念の為、テンプレートバグの根本解決まで下記のテキスト在庫表を残す。
<pre>
---------------------------------------------------------------------------------------------------
登録 | 品名 |メーカー名 | 置場 | 在庫 | 定価 | |
ﾅﾝﾊﾞｰ | | | | 単位 |在庫量 | 単位 |定価 | コメント |
---------------------------------------------------------------------------------------------------
00000 |電気ｹｰﾌﾞﾙ 直径9mm |ﾅﾅﾋﾞｼ電気 |ｹｰﾌﾞﾙ | ﾒｰﾄﾙ |50 m | 円 |15000 円 | |
---------------------------------------------------------------------------------------------------
00001 |電源 200V |ﾛﾑｵﾝ電気 |電源 | 個 |8 個 | 円 |89000 円 | |
--------------------------------------------------------------------------------------------------
</pre> ※ コラム内は現状ではwikitableが効かないので、テキスト表記のテーブルで我慢してください。
-->
{| class="wikitable"
|+ 在庫データベース画面 1/1
! rowspan="2" | 登録<br>ﾅﾝﾊﾞｰ !! rowspan="2" | 品名 !! rowspan="2" | メーカー名 !! rowspan="2" | 置場 !! colspan="2" | 在庫 !! colspan="2" | 定価 !! rowspan="2" | コメント
|-
! 単位 !! 数量 !! 単位 !! 定価
|-
! 00000
| 電気ｹｰﾌﾞﾙ 直径9mm || ﾅﾅﾋﾞｼ電気 || 電気ｹｰﾌﾞﾙ || ﾒｰﾄﾙ || 50 m || 円 || 15000 円 ||
|-
! 00001
| 電源 200V || ﾛﾑｵﾝ電気 || 電源 || 個 || 8 個 || 円 || 89000 円 ||
|}
登録ナンバーは「00001」のように空白の桁は「0」で左詰されます。なぜなら、印刷抜けによって「80001」が「 1」になるようなミスを防ぐためです。
また、「直径9mm」のような、自社でのその部品の利用で重要な情報は、品名データに入力してしまいます。
なぜなら、ケーブル以外の部品もあるわけで、たとえば
:「電源 200V、ﾛﾑｵﾝ電気、型式: GFU-BT57」
みたいに、別の種類の在庫もあるわけなので、もし項目をいちいち「直径」項目、「電圧」（V）項目とか作成していたら、商品の種類が増えるごとにどんどん項目を増やさなくてはならなくなり、在庫管理の項目作成画面を操作しなければらず、かなり煩雑です。
なので、なるべく、どの部品にも共通して存在する「品名」「業者名」「型式」以外の情報は、「品名」項目または「末尾コメント」に混ぜてしまいます。
スーパーについても、思い起こしてみれば、値札を見れば「牛乳 1000mL ヤマダ乳業 150円」みたいな書き方だったりする場合もあります。たぶん在庫管理ソフト的な設備をもとに印刷してるんだろうと思います（推測）
;「定価」項目
どの在庫管理ソフトにも「定価」項目または類似する価格の項目があり、この項目の意義は、営業部門が、その部品を使った自社製品の予想原価の見積もりを出したりするのに必要です。
このため、在庫管理ソフトは一般に、けっして在庫管理部門だけが閲覧できるのではなく、閲覧だけなら営業部門や設計部門も出来ます。
一方、在庫管理ソフトのデータ入力の権限だけが、在庫管理担当である資材部や購買部の権限です。
なので、つまり在庫管理ソフトは、在庫管理サーバとのアクセス機能が必要であることと、「閲覧限定モード」および「入力モード」の別々の機能が必要です。
さらに社内インフラ的には在庫管理サーバに、営業部門や設計部門の社内イントラネット端末からアクセス可能なように社内LANを設計しなければならないわけですし、そのように社内が事前に建築工事されています。
セキュリティ的に閲覧限定モードと入力モードを確実に切り分ける方法は、ソフト自体を「閲覧限定ソフト」および「入力可能ソフト」に分けてしまう方法です。
営業部門と設計部門のパソコンには「閲覧限定ソフト」のほうだけを入れておいて、資材部（購買部）のソフトにだけ「入力可能ソフト」を入れるという、半物理的な方法がシンプルだけど確実です。
決してオブジェクト指向だのクラスだのカプセル化だの、ややこしい方法を使わなくても、「物理的に閲覧ソフトと入力ソフトを分ける」という方法で、異部署による誤操作を原理的に防ぐのです。
|}
| 