作ろうと思うデータベースの全体から見た構想を立てる。小説やゲームなどでいう世界観だろうか。
その中のデータを、動きのある物にするか固定にするかだが、これはプレーヤーなのかNPCなのかというところか。
先ずはデータの範囲を予想して、その範囲に有ったデータ型を用意しないといけない。
キーになるデータを決めて、そのキーに対応したリレーションを取れるように考える。
キーの数はその時々で変わるし、途中で変更もありだが何度も変更する様では、手間がかかりすぎる。この辺が経験が物をいうところになる。
データの転がしも、動きの途中で考えておかないと、いきなり結果を求めたシステムだと無理があって使いにくい物になりがちだ。
転がし方も、最終データ出力の為なのか、途中のシステムの効率の為なのか。システムの要になるものなのかといった方向性で変化する。
私の作ったデータベーステーブルを例に出すと、手入力で間違いの多いデータをユニークな短縮形に変化させて間違い、勘違いの要素を極力減らし、短縮名称をキーに品名マスターとのリレーション（関係）して正式名称やコードを取得する。
ここまで書いて、データベースって何のアプリケーションを指して言っているのか？って疑問が沸いたかも知れないが、使う道具は関係ないのだ。どんなものでも、そのシステムの仕組みを分かって作っていくと、後はプログラミングコードを実装してゆくだけの作業が残っているだけだからだ。
プログラムを作るのではなくシステムとして考えて、後は単純にコーディングするだけなのだ。
慣れると、システムが天から降りてくるような感じで一瞬でアイデアが沸くものだ。その時にコーディングの種類やプログラム言語の方言を知って要れば、何をコーディングしたいのかも自ずと解るものだ。
話はそれたが、手入力データは間違いが多いものである。それをそのままデータベースで使うとなると至難の技だし、間違えるなと言うのも酷な話である。
間違えを減らすために、コード番号などを決めて入力したり、3文字アルファベットなど覚えやすい形にした名前に変更したりと工夫するものだが、情報の冗長性と言うのに幅を持たせるとそれに伴って間違いも発生しやすい。
漢字などでも、読みが同一でも一見同じに見えて詳細な部品構成の異なる字が複数ある物もあり、ユニークとは言えない。フォントとしてみると、一種の芸術作品の様に同じ形は無いものだ。
それらの違いを、全て共通フォントで長音、濁点、破裂音などを省いて共通化の一助にしているのだ。
例） シミュレーション ＝＞ シミレシン といった様な形に変える。
これなら、元がシュミレーション でも シミレシン になるのでよくある間違え方の差はなくなる。
製品名などにこれを当てはめると、そこまで微妙なネーミングしている会社も無いことだろうから、こういった手法も有効に働くと考える。
自社の製品でも、数多くあったり英名やカタカナ・ひらがな表記で読みがバラバラになってしまうものも多々あるだろうから間違えるなっていう精神論で仕事をすすめても無理が出るものだ。
同じく、フリーで書かれた文章をテキスト文字に起こしたりするのも難があるので、入力は表計算などで項目ぐらいは固定位置で書かれたものでないと、データとして使うには敷居が高くなる。
最低ラインで、表計算の固定位置に手入力と言うのが元データとしては譲れないレベルだろうか？
一方の、コーディング作業ではデータベースに用いられるSQL言語のコマンド数やその影響やカバーする範囲の広さもあって、他のプログラム言語と比較にならないぐらい少ない行数（コーディング数）でプログラムが簡潔に書けるのも魅力の一つだ。
UNIXのshコマンドなどの中で使われるパイプライン的なデータの扱いに慣れていると、更にSQLの応用範囲は広がる。
データをユニーク化することに成功したら、後はそれをキーとしてマスターデータとリレーションを繰り替えして、欲しいデータまで加工するのみだ。
主要なデータの流れで説明すると製品名、生産量、生産日１から生産日３１というデータの並びがあって、
それを、製品名の短縮名称に変換した物、生産量、その生産の日付けというデータに変化させる。
この変化までに、省略出来る長音・濁点・記号などを取ってしまい。各日付けの位置のデータの有る無しで、データのあったものだけを抽出して、該当日付けのデータと共に新規にテーブルに追加する。
例）
（数量）／日付け １ ２ ３ ４ ５ …
名称
ホットケーキ １ ３ ５
ジャム １ ２ １
はちみつ １ １
バター １
こんな感じでデータが有れば、
ホトケキ １ ３ ５
シム １ ２ １
ハチミツ １ １
ハタ １
と省略して
省略名 日 数
ホトケキ １ １
ホトケキ ３ ３
ホトケキ ４ ５
シム １ １
シム ３ ２
シム ４ １
ハチミツ ２ １
ハチミツ ４ １
ハタ ２ １
とデータベースとしては良い形まで変形するのだ。
これを、短縮品名、品コード、正式製品名の入ったマスターとリレーションする。
マスターは、こんな感じ。
短縮品名 品コード 正式製品名
ホトケキ ０００１ ホットケーキ
シム ０００２ ジャム
ハチミツ ０００３ 蜂蜜
ハタ ０００４ バター
データベース処理の途中では、コードを扱った方が桁数による必要容量は少なくなり、処理速度は上がる。このマスターとリレーションした後に
品コード 日 数
０００１ １ １
０００１ ３ ３
０００１ ４ ５
０００２ １ １
０００２ ３ ２
０００２ ４ １
０００３ ２ １
０００３ ４ １
０００４ ２ １
と形を変える
で、それぞれのレシピ・処方をデータに持っている原単位マスターとリレーションする。原単位マスターはこんな感じ
品コード 原料コード 数量
0001 0001 300
0001 0002 200
0001 0003 10
0001 0004 10
0001 0005 1
0001 0006 20
0001 0012 2
0002 0006 200
0002 0007 300
0002 0008 50
0003 0009 500
0004 0010 500
0004 0011 15
原料名のマスターもいる。作り方によっては製品名と同一のマスターに組み込んでもOKだが、ここでは話が分かりやすくするため別のマスターとしておく。
原料コード 原料名
０００１ 小麦粉（薄力粉）
０００２ 水
０００３ バター
０００４ ジャム
０００５ 卵
０００６ 砂糖
０００７ いちご
０００８ ゼラチン
０００９ 蜂蜜
００１０ 牛乳
００１１ 塩
００１２ ベーキングパウダー
ここまでで、データの数字の品コード・原料コードも文字も全てテキストデータで数量のみ数値のデータ型を用意した方が、後の処理としては扱いやすいだろう。これでメインキャストは揃ったことになる。この出会い（リレーション）は次の回に説明することにする。
注意） ここで取り上げているデータ並びに例題は、思いつくまま上げているだけで、実際の処方やレシピとは無関係です。これによって味などに不都合が生じても一切の保証は致しませんので悪しからず。
又、説明のため、厳密にデータの半角倍角やコード化の有効な手法などの区別していません。
この生データをそのまま使い動作を試みられても動くことは無いと思います。
あくまで、イメージとして捉えてください。
その中のデータを、動きのある物にするか固定にするかだが、これはプレーヤーなのかNPCなのかというところか。
先ずはデータの範囲を予想して、その範囲に有ったデータ型を用意しないといけない。
キーになるデータを決めて、そのキーに対応したリレーションを取れるように考える。
キーの数はその時々で変わるし、途中で変更もありだが何度も変更する様では、手間がかかりすぎる。この辺が経験が物をいうところになる。
データの転がしも、動きの途中で考えておかないと、いきなり結果を求めたシステムだと無理があって使いにくい物になりがちだ。
転がし方も、最終データ出力の為なのか、途中のシステムの効率の為なのか。システムの要になるものなのかといった方向性で変化する。
私の作ったデータベーステーブルを例に出すと、手入力で間違いの多いデータをユニークな短縮形に変化させて間違い、勘違いの要素を極力減らし、短縮名称をキーに品名マスターとのリレーション（関係）して正式名称やコードを取得する。
ここまで書いて、データベースって何のアプリケーションを指して言っているのか？って疑問が沸いたかも知れないが、使う道具は関係ないのだ。どんなものでも、そのシステムの仕組みを分かって作っていくと、後はプログラミングコードを実装してゆくだけの作業が残っているだけだからだ。
プログラムを作るのではなくシステムとして考えて、後は単純にコーディングするだけなのだ。
慣れると、システムが天から降りてくるような感じで一瞬でアイデアが沸くものだ。その時にコーディングの種類やプログラム言語の方言を知って要れば、何をコーディングしたいのかも自ずと解るものだ。
話はそれたが、手入力データは間違いが多いものである。それをそのままデータベースで使うとなると至難の技だし、間違えるなと言うのも酷な話である。
間違えを減らすために、コード番号などを決めて入力したり、3文字アルファベットなど覚えやすい形にした名前に変更したりと工夫するものだが、情報の冗長性と言うのに幅を持たせるとそれに伴って間違いも発生しやすい。
漢字などでも、読みが同一でも一見同じに見えて詳細な部品構成の異なる字が複数ある物もあり、ユニークとは言えない。フォントとしてみると、一種の芸術作品の様に同じ形は無いものだ。
それらの違いを、全て共通フォントで長音、濁点、破裂音などを省いて共通化の一助にしているのだ。
例） シミュレーション ＝＞ シミレシン といった様な形に変える。
これなら、元がシュミレーション でも シミレシン になるのでよくある間違え方の差はなくなる。
製品名などにこれを当てはめると、そこまで微妙なネーミングしている会社も無いことだろうから、こういった手法も有効に働くと考える。
自社の製品でも、数多くあったり英名やカタカナ・ひらがな表記で読みがバラバラになってしまうものも多々あるだろうから間違えるなっていう精神論で仕事をすすめても無理が出るものだ。
同じく、フリーで書かれた文章をテキスト文字に起こしたりするのも難があるので、入力は表計算などで項目ぐらいは固定位置で書かれたものでないと、データとして使うには敷居が高くなる。
最低ラインで、表計算の固定位置に手入力と言うのが元データとしては譲れないレベルだろうか？
一方の、コーディング作業ではデータベースに用いられるSQL言語のコマンド数やその影響やカバーする範囲の広さもあって、他のプログラム言語と比較にならないぐらい少ない行数（コーディング数）でプログラムが簡潔に書けるのも魅力の一つだ。
UNIXのshコマンドなどの中で使われるパイプライン的なデータの扱いに慣れていると、更にSQLの応用範囲は広がる。
データをユニーク化することに成功したら、後はそれをキーとしてマスターデータとリレーションを繰り替えして、欲しいデータまで加工するのみだ。
主要なデータの流れで説明すると製品名、生産量、生産日１から生産日３１というデータの並びがあって、
それを、製品名の短縮名称に変換した物、生産量、その生産の日付けというデータに変化させる。
この変化までに、省略出来る長音・濁点・記号などを取ってしまい。各日付けの位置のデータの有る無しで、データのあったものだけを抽出して、該当日付けのデータと共に新規にテーブルに追加する。
例）
（数量）／日付け １ ２ ３ ４ ５ …
名称
ホットケーキ １ ３ ５
ジャム １ ２ １
はちみつ １ １
バター １
こんな感じでデータが有れば、
ホトケキ １ ３ ５
シム １ ２ １
ハチミツ １ １
ハタ １
と省略して
省略名 日 数
ホトケキ １ １
ホトケキ ３ ３
ホトケキ ４ ５
シム １ １
シム ３ ２
シム ４ １
ハチミツ ２ １
ハチミツ ４ １
ハタ ２ １
とデータベースとしては良い形まで変形するのだ。
これを、短縮品名、品コード、正式製品名の入ったマスターとリレーションする。
マスターは、こんな感じ。
短縮品名 品コード 正式製品名
ホトケキ ０００１ ホットケーキ
シム ０００２ ジャム
ハチミツ ０００３ 蜂蜜
ハタ ０００４ バター
データベース処理の途中では、コードを扱った方が桁数による必要容量は少なくなり、処理速度は上がる。このマスターとリレーションした後に
品コード 日 数
０００１ １ １
０００１ ３ ３
０００１ ４ ５
０００２ １ １
０００２ ３ ２
０００２ ４ １
０００３ ２ １
０００３ ４ １
０００４ ２ １
と形を変える
で、それぞれのレシピ・処方をデータに持っている原単位マスターとリレーションする。原単位マスターはこんな感じ
品コード 原料コード 数量
0001 0001 300
0001 0002 200
0001 0003 10
0001 0004 10
0001 0005 1
0001 0006 20
0001 0012 2
0002 0006 200
0002 0007 300
0002 0008 50
0003 0009 500
0004 0010 500
0004 0011 15
原料名のマスターもいる。作り方によっては製品名と同一のマスターに組み込んでもOKだが、ここでは話が分かりやすくするため別のマスターとしておく。
原料コード 原料名
０００１ 小麦粉（薄力粉）
０００２ 水
０００３ バター
０００４ ジャム
０００５ 卵
０００６ 砂糖
０００７ いちご
０００８ ゼラチン
０００９ 蜂蜜
００１０ 牛乳
００１１ 塩
００１２ ベーキングパウダー
ここまでで、データの数字の品コード・原料コードも文字も全てテキストデータで数量のみ数値のデータ型を用意した方が、後の処理としては扱いやすいだろう。これでメインキャストは揃ったことになる。この出会い（リレーション）は次の回に説明することにする。
注意） ここで取り上げているデータ並びに例題は、思いつくまま上げているだけで、実際の処方やレシピとは無関係です。これによって味などに不都合が生じても一切の保証は致しませんので悪しからず。
又、説明のため、厳密にデータの半角倍角やコード化の有効な手法などの区別していません。
この生データをそのまま使い動作を試みられても動くことは無いと思います。
あくまで、イメージとして捉えてください。