http://system.pgtop.net/ プログラミング言語やデータベースを使って、業務システムを開発する実践講座です。 ja http://blogs.law.harvard.edu/tech/rss プログラミング言語やデータベースを使って、業務システムを開発する実践講座です。 プログラミング,データベース,システム開発,プログラム,実践 mslab no http://system.pgtop.net/article/445936319.html Sun, 15 Jan 2017 10:12:41 +0900 システム開発でデータベースを使う時には、売上伝票のようにデータを鑑部と明細に分けることがよくあります。前回までに、鑑部を表形式にして、その後にテーブルの正規化を行いました。次は明細部分の正規化が必要ですが、その前に、今回は明細を表形式にするところから始めましょう。これまでに行っている部分の復習です。売上伝票を鑑部と明細部に切り分け、関連付けるために、明細部に「伝票No」の項目(列)を加え、明細部の各行を、一意に識別するため、主キーとして「明細No」を加えた状態がこれです。・明.. ＊一意とは、同じデータが他に無く、重複しないことです。 ＊主キー(primary key)とは、レコードを「一意」に識別するためのフィールドです。 ＊明細部での 伝票No は主キーではなく、外部キーなので、重複してもOKです。 思い出しましたか？ やっと準備が整いましたｗ リレーショナルデータベースで、データをテーブルに保存するには、 列と行からなる表形式にする必要があります。 それでは明細を表形式にしてみましょう。 とても簡単です。 上図をそのまま表形式にするだけですから。 表形式にすると、こうなります。 一つだけ変更した点は、 明細で「品名」となっている部分を、「商品名」にしたことです。 単純に列名を変えただけ。 理由は、商品名のほうが一般的で、分かりやすいからです。 このような表形式にできると、データベースやExcelのような表計算ソフトでも扱えるようになります。 どうですか？ 明細の場合、表形式にするのは、そんなに難しくありませんよね。 【補足】 ただし、今の状態では、まだテーブルが正規化されていません。 正規化は次回のステップで行います。 ]]> システム開発でデータベースを使う時には、売上伝票のようにデータを鑑部と明細に分けることがよくあります。

前回までに、鑑部を表形式にして、その後にテーブルの正規化を行いました。

次は明細部分の正規化が必要ですが、

その前に、今回は明細を表形式にするところから始めましょう。

これまでに行っている部分の復習です。

売上伝票を鑑部と明細部に切り分け、
関連付けるために、
明細部に「伝票No」の項目(列)を加え、
明細部の各行を、一意に識別するため、主キーとして「明細No」を加えた状態がこれです。

・明細部


＊一意とは、同じデータが他に無く、重複しないことです。
＊主キー(primary key)とは、レコードを「一意」に識別するためのフィールドです。
＊明細部での 伝票No は主キーではなく、外部キーなので、重複してもOKです。

思い出しましたか？

やっと準備が整いましたｗ

リレーショナルデータベースで、データをテーブルに保存するには、

列と行からなる表形式にする必要があります。

それでは明細を表形式にしてみましょう。

とても簡単です。

上図をそのまま表形式にするだけですから。

表形式にすると、こうなります。



一つだけ変更した点は、

明細で「品名」となっている部分を、「商品名」にしたことです。

単純に列名を変えただけ。

理由は、商品名のほうが一般的で、分かりやすいからです。

このような表形式にできると、データベースやExcelのような表計算ソフトでも扱えるようになります。

どうですか？

明細の場合、表形式にするのは、そんなに難しくありませんよね。

【補足】
ただし、今の状態では、まだテーブルが正規化されていません。

正規化は次回のステップで行います。

]]> Step8・明細を表形式にする mslab blog:https://blog.seesaa.jp,syspg/445936319 http://system.pgtop.net/article/432508230.html Wed, 13 Jan 2016 12:55:21 +0900 システム開発でデータベースを使うには、データを保存するテーブルの正規化が必要です。システム開発で言うテーブルの正規化とは、データをルールに従って、利用しやすい形にすることです。テーブルの正規化については、これまでの記事でも説明しています。コツは「繰り返し入力する可能性のあるものは、別のテーブルに分ける」ということでしたね。テーブルを正規化することで、同じデータを何度も入力する手間が省けます。正規化されたテーブルは、ほとんどの列が数字になります。数値を入力、選択するだけなので、.. でもこの状態では、まだテーブルが正規化されていません。 繰り返し入力される可能性のある列が、いくつもあるからです。 まず、伝票Noは重複することが無いので、そのままでOKです。 日付は重複しますが、これだけは例外的にOKです。 普通の会社では、同じ日にいくつも伝票が発生します。 するともちろん、日付が重複します。 でも業務システム側で、当日の日付を自動入力することは簡単ですし、 カレンダーから選択できるようにすることも可能です。 だから日付を別テーブルに分ける必要は無いのです。 次は顧客名です。 伝票は1回の買い物ごとに発生します。 同日でも別日でもいいのですが、同じお客様が何度も買い物をする可能性は十分ありますよね。 だから顧客名は、重複するデータということになります。 顧客マスターテーブルを別に作ったほうが良いわけです。 承認印と係印はどうでしょうか？ 本来、紙の伝票では、社員が印鑑を押すところです。 社員名が入っていますよね。 同じ社員が複数の売上伝票に押印ことは十分考えられます。 社内では仕事の役割や役職が決まっているはずなので、 同じ社員が何度も押すと考えるほうが普通です。 だからこの部分は、重複するデータです。 ということは、社員マスターテーブルを別に作ったほうが良いわけです。 以上の事から、売上伝票の鑑部のテーブルを正規化すると、 ・売上伝票(鑑部) ・顧客マスター ・社員マスター の各テーブルができます。 売上伝票には、数字が入力されている点がポイントです。 日付は表示形式だけの問題です。数字と記号で入力することも可能。 このように正規化されたテーブルでは、メインのテーブルには、ほとんど数字が並ぶことになります。 必要に応じて、他のテーブルを参照すれば、顧客名や社員名が分かります。 また結婚などによって、社員の姓が変わった場合でも、社員マスター側を変更するだけで済み、メインの売上伝票には影響しないのもメリットです。 これがリレーショナルデータベースの考え方です。 ]]> システム開発でデータベースを使うには、データを保存するテーブルの正規化が必要です。

システム開発で言うテーブルの正規化とは、
データをルールに従って、利用しやすい形にすることです。

テーブルの正規化については、これまでの記事でも説明しています。

コツは「繰り返し入力する可能性のあるものは、別のテーブルに分ける」ということでしたね。

テーブルを正規化することで、同じデータを何度も入力する手間が省けます。

正規化されたテーブルは、ほとんどの列が数字になります。

数値を入力、選択するだけなので、文字列の場合より入力ミスが防げます。

それに数字のほうが文字列より、データベースへの保存時の容量が少なくて済むメリットがあります。

前回、売上伝票の鑑部を表形式にするところまでやりました。



でもこの状態では、まだテーブルが正規化されていません。

繰り返し入力される可能性のある列が、いくつもあるからです。

まず、伝票Noは重複することが無いので、そのままでOKです。

日付は重複しますが、これだけは例外的にOKです。

普通の会社では、同じ日にいくつも伝票が発生します。

するともちろん、日付が重複します。

でも業務システム側で、当日の日付を自動入力することは簡単ですし、
カレンダーから選択できるようにすることも可能です。

だから日付を別テーブルに分ける必要は無いのです。

次は顧客名です。

伝票は1回の買い物ごとに発生します。

同日でも別日でもいいのですが、同じお客様が何度も買い物をする可能性は十分ありますよね。

だから顧客名は、重複するデータということになります。

顧客マスターテーブルを別に作ったほうが良いわけです。

承認印と係印はどうでしょうか？

本来、紙の伝票では、社員が印鑑を押すところです。

社員名が入っていますよね。

同じ社員が複数の売上伝票に押印ことは十分考えられます。

社内では仕事の役割や役職が決まっているはずなので、
同じ社員が何度も押すと考えるほうが普通です。

だからこの部分は、重複するデータです。

ということは、社員マスターテーブルを別に作ったほうが良いわけです。

以上の事から、売上伝票の鑑部のテーブルを正規化すると、
・売上伝票(鑑部)
・顧客マスター
・社員マスター
の各テーブルができます。



売上伝票には、数字が入力されている点がポイントです。

日付は表示形式だけの問題です。数字と記号で入力することも可能。

このように正規化されたテーブルでは、メインのテーブルには、ほとんど数字が並ぶことになります。

必要に応じて、他のテーブルを参照すれば、顧客名や社員名が分かります。

また結婚などによって、社員の姓が変わった場合でも、社員マスター側を変更するだけで済み、メインの売上伝票には影響しないのもメリットです。

これがリレーショナルデータベースの考え方です。

]]> Step7・鑑部のテーブルを正規化 mslab blog:https://blog.seesaa.jp,syspg/432508230 http://system.pgtop.net/article/411832518.html Mon, 05 Jan 2015 14:32:39 +0900 システム開発では、データベースを使うため、データはテーブルに保存することになります。AccessやMySQLのようなリレーショナルデータベースで、データをテーブルに保存するには、列と行からなる表形式にする必要があります。システム開発初心者が、最初に難しく感じるのは、現実のデータ(帳票やレシートなどの印刷物)を、どうやってデータベースのテーブルの形に表現するかです。でも、順序良く、分解して考えれば、意外と簡単にできます。そこでまずは、売上伝票の鑑部を表形式にしてみましょう。元は.. 鑑部にあるデータを、1行に抜き出すと、こんな感じになります。 このように、分解して並べ替えてみるのがコツです。 リアルな印刷物の場合は、ハサミで切って、机の上で、 実際に並べ替えてみるとよいでしょう。 大事な書類の場合は、コピーしたものを切ってくださいね。 ここまでの考え方、手順は簡単ですよね？ あとは表形式にすると、こうなります。 一つだけ変更した点は、 元の鑑部で「No.」となっている部分を、「伝票No」にしたことです。 単純に列名を変えただけ。 理由は、後で作る明細と関連付けるためです。 このような表形式にできると、データベースでもExcelのような表計算ソフトでも扱えるようになります。 どうですか？ データベースのテーブルにするのは、そんなに難しくないことが分かったと思います。 【補足】 今の状態では、まだテーブルが正規化されていません。 ]]> システム開発では、データベースを使うため、データはテーブルに保存することになります。

AccessやMySQLのようなリレーショナルデータベースで、

データをテーブルに保存するには、

列と行からなる表形式にする必要があります。

システム開発初心者が、最初に難しく感じるのは、

現実のデータ(帳票やレシートなどの印刷物)を、

どうやってデータベースのテーブルの形に表現するかです。

でも、順序良く、分解して考えれば、意外と簡単にできます。

そこでまずは、売上伝票の鑑部を表形式にしてみましょう。

元はこんな状態です。

・鑑部



鑑部にあるデータを、1行に抜き出すと、こんな感じになります。



このように、分解して並べ替えてみるのがコツです。

リアルな印刷物の場合は、ハサミで切って、机の上で、

実際に並べ替えてみるとよいでしょう。

大事な書類の場合は、コピーしたものを切ってくださいね。

ここまでの考え方、手順は簡単ですよね？


あとは表形式にすると、こうなります。



一つだけ変更した点は、

元の鑑部で「No.」となっている部分を、「伝票No」にしたことです。

単純に列名を変えただけ。

理由は、後で作る明細と関連付けるためです。

このような表形式にできると、データベースでもExcelのような表計算ソフトでも扱えるようになります。

どうですか？

データベースのテーブルにするのは、そんなに難しくないことが分かったと思います。

【補足】
今の状態では、まだテーブルが正規化されていません。

]]> Step6・鑑部を表形式にする mslab blog:https://blog.seesaa.jp,syspg/411832518 http://system.pgtop.net/article/111543212.html Mon, 22 Dec 2008 11:07:11 +0900 リレーショナルデータベースを用いた システム開発 では、複数のテーブル同士を関連付けることで、目的のデータを得ます。前回のように、売上伝票をただ分けただけでは、鑑部と明細部のつながりが無くなってしまいます。すると、どの明細部が、どの鑑部のものなのかがわかりません。【1】そこで、明細部に「伝票No」の項目(列)を加えます。＊計算部分は省略しました。これだけで関連付けは完了です。簡単ですよね。伝票No が両方にあることで、どの鑑部の明細部なのか、判断できるようになりました。つまり.. ＊計算部分は省略しました。 これだけで関連付けは完了です。簡単ですよね。 伝票No が両方にあることで、どの鑑部の明細部なのか、判断できるようになりました。つまり同じテーブルに、異なる鑑部の明細部を保存しておいても、区別することができます。 あと、もう一つ付け加える項目があります。 【2】明細部の各行を、一意に識別するため、主キーとして「明細No」を加えます。 ＊一意とは、同じデータが他に無く、重複しないことです。 ＊主キー(primary key)とは、レコードを「一意」に識別するためのフィールドです。 主キーである 明細No が「1」のレコードは、必ず1件しかありません。 したがって、たとえ伝票No、品名、数量、単価が同じでも、明細Noが異なれば、違うレコードだと識別できるわけです。 また、明細部での 伝票No は主キーではなく、外部キーなので、重複してもOKです。伝票Noが重複しているものが、同じ鑑部に属するレコードだとわかります。 【3】ここまでの作業をまとめると、以下のようになります。 ・鑑部 ・明細部 【ワンポイント】 鑑部の主キーには、「No」の項目を「伝票No」として、そのまま使うことができます。 主キーには、数値型のフィールドを使うのが一般的です。 もし、伝票番号に意味を持たせたい場合は、「H20-12-22-0001」のような文字列で入力できるフィールドを、新たに用意したほうが良いでしょう。 ]]> システム開発 では、複数のテーブル同士を関連付けることで、目的のデータを得ます。

前回のように、売上伝票をただ分けただけでは、鑑部と明細部のつながりが無くなってしまいます。すると、どの明細部が、どの鑑部のものなのかがわかりません。

【1】そこで、明細部に「伝票No」の項目(列)を加えます。



＊計算部分は省略しました。

これだけで関連付けは完了です。簡単ですよね。

伝票No が両方にあることで、どの鑑部の明細部なのか、判断できるようになりました。つまり同じテーブルに、異なる鑑部の明細部を保存しておいても、区別することができます。


あと、もう一つ付け加える項目があります。

【2】明細部の各行を、一意に識別するため、主キーとして「明細No」を加えます。



＊一意とは、同じデータが他に無く、重複しないことです。
＊主キー(primary key)とは、レコードを「一意」に識別するためのフィールドです。

主キーである 明細No が「1」のレコードは、必ず1件しかありません。

したがって、たとえ伝票No、品名、数量、単価が同じでも、明細Noが異なれば、違うレコードだと識別できるわけです。

また、明細部での 伝票No は主キーではなく、外部キーなので、重複してもOKです。伝票Noが重複しているものが、同じ鑑部に属するレコードだとわかります。


【3】ここまでの作業をまとめると、以下のようになります。

・鑑部


・明細部



【ワンポイント】
鑑部の主キーには、「No」の項目を「伝票No」として、そのまま使うことができます。



主キーには、数値型のフィールドを使うのが一般的です。

もし、伝票番号に意味を持たせたい場合は、「H20-12-22-0001」のような文字列で入力できるフィールドを、新たに用意したほうが良いでしょう。

]]> Step5・鑑部と明細部を関連付ける mslab blog:https://blog.seesaa.jp,syspg/111543212 http://system.pgtop.net/article/111392342.html Thu, 18 Dec 2008 10:45:56 +0900 システム開発 の基本となる売上伝票では、1つの伝票を、「鑑部と明細部に分ける」という考え方が、とても重要です。システム開発初心者にとっては、一番難しい部分ですが、この考え方が理解できれば、ほとんどの業務システムに応用することができます。そこで今回は、計算で出せる項目を省略した売上伝票を、さらに鑑部と明細部に分けてみましょう。・計算項目を省略した売上伝票上の売上伝票を、以下のように、鑑部と明細部の2つに分けます。・鑑部・明細部分けること自体は、とても簡単ですね。鑑部と明細部を別.. 上の売上伝票を、以下のように、鑑部と明細部の2つに分けます。 ・鑑部 ・明細部 分けること自体は、とても簡単ですね。 鑑部と明細部を別々に見ると、何となくテーブルにできそうな感じになってきました。複雑なものでも、分解すると簡単になることがわかります。 1件の売上伝票に対して、鑑部は1つですが、明細部は複数行あります。 商品が1つしか売れない場合もあるし、2つ以上売れる場合もあるので、明細部の行数は、常に変わるという点がポイントです。 また鑑部があって、明細部が無い状態というのは、商品がまだ売れていないということになります。(新規入力中など) 【解説】 (1)鑑部のことを「売上上部」、「伝票上部」、「売上メイン」、「伝票メイン」ということもあります。 (2)明細部のことを「売上明細」、「伝票明細」、「売上明細行」、「伝票明細行」ということもあります。 ]]> システム開発 の基本となる売上伝票では、1つの伝票を、「鑑部と明細部に分ける」という考え方が、とても重要です。

システム開発初心者にとっては、一番難しい部分ですが、この考え方が理解できれば、ほとんどの業務システムに応用することができます。

そこで今回は、計算で出せる項目を省略した売上伝票を、さらに鑑部と明細部に分けてみましょう。

・計算項目を省略した売上伝票



上の売上伝票を、以下のように、鑑部と明細部の2つに分けます。

・鑑部


・明細部


分けること自体は、とても簡単ですね。

鑑部と明細部を別々に見ると、何となくテーブルにできそうな感じになってきました。複雑なものでも、分解すると簡単になることがわかります。

1件の売上伝票に対して、鑑部は1つですが、明細部は複数行あります。

商品が1つしか売れない場合もあるし、2つ以上売れる場合もあるので、明細部の行数は、常に変わるという点がポイントです。

また鑑部があって、明細部が無い状態というのは、商品がまだ売れていないということになります。(新規入力中など)


【解説】
(1)鑑部のことを「売上上部」、「伝票上部」、「売上メイン」、「伝票メイン」ということもあります。

(2)明細部のことを「売上明細」、「伝票明細」、「売上明細行」、「伝票明細行」ということもあります。

]]> Step4・売上伝票を鑑部と明細部に分ける mslab blog:https://blog.seesaa.jp,syspg/111392342 http://system.pgtop.net/article/111069403.html Thu, 11 Dec 2008 17:03:46 +0900 業務システムの システム開発 では、消費税率を頻繁に扱います。消費税率を扱う時には、注意するポイントがあるので、まとめておきます。消費税率は、売上伝票の日付から、プログラムで計算することができます。・1989年4月1日以降から1997年3月末日までは3%・1997年4月1日以降は5%消費税率は、1989年(平成元年)4月1日に施行されました。当時の消費税率は 3% でしたが、1997年(平成9年)4月1日には、5%に引き上げられました。消費税は、商品やサービスに課税されます。.. ]]> システム開発 では、消費税率を頻繁に扱います。

消費税率を扱う時には、注意するポイントがあるので、まとめておきます。

消費税率は、売上伝票の日付から、プログラムで計算することができます。
・1989年4月1日以降から1997年3月末日までは3%
・1997年4月1日以降は5%

消費税率は、1989年(平成元年)4月1日に施行されました。当時の消費税率は 3% でしたが、1997年(平成9年)4月1日には、5%に引き上げられました。

消費税は、商品やサービスに課税されます。私達が何かを購入する時には、ほとんどのものに消費税がかかっています。

また消費税率は、将来的に変化する可能性が、十分あります。

医療や介護の水準を維持するためには、財源が必要で、それを消費税で賄うなら、税率を引き上げる必要があると言われています。

2008年12月の現時点では、商品の合計に消費税率の5%をかければ、消費税額が出せます。一見簡単なようですが・・・

実は、消費税が課税されない商品やサービスがあります。医療や福祉、教育などは、対象外となっています。

そのため、課税・非課税の両方の商品やサービスを扱う場合は、結構計算が複雑です。

商品ごとに課税・非課税があるのなら、商品テーブルに税率を持たせておく方法も考えられます。

しかし将来、税率が変わった場合、商品テーブルの税率を変更すると、過去の消費税額が変わってしまいます。

したがって、データを「転記」するなどの工夫が必要になります。

つまり、きちんとした業務システムを作るなら、単純な計算では出せないわけです。

でも最初から深く考えすぎると、肝心な「テーブル設計」まで難しく感じてしまいます。そこで、とりあえず消費税額は、商品の合計に 5%をかけて計算することにしておきます。

売上伝票の全体像を把握した段階で、いくらでも改善することはできます。まずはデータベースのテーブル設計に集中することにしましょう。

]]> Step3・消費税率について mslab blog:https://blog.seesaa.jp,syspg/111069403 http://system.pgtop.net/article/111050158.html Thu, 11 Dec 2008 10:06:15 +0900 システム開発 で、データベースのテーブルを設計する時、後から計算で出せるデータは、保存しないのが基本です。売上伝票は、一見複雑そうです。初心者はどこから手をつけてよいのか、わからないかもしれません。しかし段階を踏んで考えると、必ずわかるようになります。それでは、売上伝票をじっくり分析してみましょう。【1】まず、計算で出せる項目を考えてみます。・売上伝票金額(税抜)：数量と単価から計算できる合計：金額を集計すると計算できる税率：日付から計算できる消費税額等：合計と税率から計算で.. 金額(税抜)：数量と単価から計算できる 合計：金額を集計すると計算できる 税率：日付から計算できる 消費税額等：合計と税率から計算できる 税込合計金額：合計と消費税額等、または合計と税率から計算できる 【2】そこで、計算で出すことが出来るデータを省くと、以下のようになります。 これでかなりスッキリしましたね。何だか簡単になったような気がしませんか？ 計算できる項目は、データを保存しておく必要がないので、項目自体を消しています。省略した項目は、後で演算フィールドで計算して表示できます。 残った項目が、テーブルに保存する各フィールドになります。 【解説】 (1)税率(消費税率)は、過去に 3%から 5%に上がりました。今後も変化する可能性が十分あります。また消費税がかからないものもあります。 税率については、主に3通りの考え方があります。 ・税率は売上伝票の日付から計算できる ・売上伝票のテーブルに税率を保存しておく ・税率用にテーブルを作成し、参照する どの方法でも可能ですが、今回はわかりやすくするため、税率を省略しました。 売上伝票の日付から計算する方法だと、税率を保存しておく必要はありませんが、表示する時には、計算する時間が必要です。 逆に税率を保存する場合は、容量が必要ですが、表示する時に計算は不要です。 税率については、後から加えることもできるので、とりあえず側に置いておいてください。 (2)基本的には、計算で出せるデータは、テーブルに保存しませんが、例外もあります。 合計や消費税額等、税込合計金額のような、計算で出せる項目(フィールド)を、あえて残し、テーブルに計算結果を保存しておくことがあります。 例えば、レコード数が多く、計算が複雑になる場合は、計算してから画面へ表示すると、時間がかかってしまいます。するとユーザーにとって、システム自体の動作が、とても遅く感じるとこがあります。 そこで、処理に余裕のある時(追加や更新時)に計算して、テーブルに保存しておきます。表示する時には、計算が不要になるので、その分システムの動作が速くなります。 また、帳票などに集計結果を表示する場合も同じで、その都度計算してから表示するより、あらかじめ計算しておいたものを表示したほうが速いです。 しかし、これらは特別な場合です。やはり基本的には、計算で出せるデータは、テーブルに保存しないと覚えてください。 ]]> システム開発 で、データベースのテーブルを設計する時、後から計算で出せるデータは、保存しないのが基本です。

売上伝票は、一見複雑そうです。初心者はどこから手をつけてよいのか、わからないかもしれません。

しかし段階を踏んで考えると、必ずわかるようになります。

それでは、売上伝票をじっくり分析してみましょう。


【1】まず、計算で出せる項目を考えてみます。

・売上伝票


金額(税抜)：数量と単価から計算できる
合計：金額を集計すると計算できる
税率：日付から計算できる
消費税額等：合計と税率から計算できる
税込合計金額：合計と消費税額等、または合計と税率から計算できる


【2】そこで、計算で出すことが出来るデータを省くと、以下のようになります。



これでかなりスッキリしましたね。何だか簡単になったような気がしませんか？

計算できる項目は、データを保存しておく必要がないので、項目自体を消しています。省略した項目は、後で演算フィールドで計算して表示できます。

残った項目が、テーブルに保存する各フィールドになります。


【解説】
(1)税率(消費税率)は、過去に 3%から 5%に上がりました。今後も変化する可能性が十分あります。また消費税がかからないものもあります。

税率については、主に3通りの考え方があります。
・税率は売上伝票の日付から計算できる
・売上伝票のテーブルに税率を保存しておく
・税率用にテーブルを作成し、参照する

どの方法でも可能ですが、今回はわかりやすくするため、税率を省略しました。

売上伝票の日付から計算する方法だと、税率を保存しておく必要はありませんが、表示する時には、計算する時間が必要です。

逆に税率を保存する場合は、容量が必要ですが、表示する時に計算は不要です。

税率については、後から加えることもできるので、とりあえず側に置いておいてください。


(2)基本的には、計算で出せるデータは、テーブルに保存しませんが、例外もあります。

合計や消費税額等、税込合計金額のような、計算で出せる項目(フィールド)を、あえて残し、テーブルに計算結果を保存しておくことがあります。

例えば、レコード数が多く、計算が複雑になる場合は、計算してから画面へ表示すると、時間がかかってしまいます。するとユーザーにとって、システム自体の動作が、とても遅く感じるとこがあります。

そこで、処理に余裕のある時(追加や更新時)に計算して、テーブルに保存しておきます。表示する時には、計算が不要になるので、その分システムの動作が速くなります。

また、帳票などに集計結果を表示する場合も同じで、その都度計算してから表示するより、あらかじめ計算しておいたものを表示したほうが速いです。

しかし、これらは特別な場合です。やはり基本的には、計算で出せるデータは、テーブルに保存しないと覚えてください。

]]> Step2・計算で出せる項目は省く mslab blog:https://blog.seesaa.jp,syspg/111050158 http://system.pgtop.net/article/111002988.html Wed, 10 Dec 2008 10:01:53 +0900 システム開発 を始める前に、これからどんなシステムを作るのか、考える必要があります。世の中には、いろんなプログラムがあります。ゲームからパソコンのソフトウェア、家電、企業の業務システムまで、現在の私達の生活は、プログラムに支えられています。あなたが普通に生活しているだけでも、裏側で多くのプログラムが動いています。テレビやビデオはもちろん、炊飯器や洗濯機にもプログラムが組み込まれています。最終的に、どんなプログラムを作れるようになりたいかで、適した学び方が変わってきます。プログ.. この売上伝票がわかれば、業務システムが全てわかるようになる、といっても過言ではありません。 売上伝票で身に付けて欲しいポイントは以下の通りです。 ・伝票と明細の関係 ・テーブル設計 ・テーブルの正規化 ・演算フィールド 売上伝票には、あらゆる分野の基礎が含まれています。売上伝票のテーブル設計や正規化の考え方は、他の業務システムにも応用することができます。 実は、複雑そうなネットショップも、売上伝票の延長線上にあります。よく考えると、ネットショップも商品やサービスを販売しているわけですから、当然ですよね。 テーブル数や入力するデータの項目は多くなりますが、基本部分は売上伝票そのものです。 つまり売上伝票が理解できれば、ネットショップも理解できるということです。 また、まったくの初心者が、システム開発を学ぶ場合、最初に売上伝票を学ぶと、その後の上達が驚くほど早く、他の業務システムもすぐに理解できるようになります。 一見遠回りのように思えますが、売上伝票はシステム開発を習得する近道なのです。 【補足】 もし、あなたが作りたいシステムが明確なら、それを作るのが一番です。または、あなたの職場の人が希望するシステムを、作ってあげるのも良いでしょう。 身近な人に頼んで、練習台になってもらうのです。すると人の意見を聞く(取り入れる)ことの練習にもなります。人の話をしっかり聞くことは、プログラマーや、特にSEには必要な能力です。 でも作りたいシステムが、まだはっきり決まっていないのなら、「売上伝票」が一番良い教材だと思います。 ]]> システム開発 を始める前に、これからどんなシステムを作るのか、考える必要があります。

世の中には、いろんなプログラムがあります。ゲームからパソコンのソフトウェア、家電、企業の業務システムまで、現在の私達の生活は、プログラムに支えられています。

あなたが普通に生活しているだけでも、裏側で多くのプログラムが動いています。テレビやビデオはもちろん、炊飯器や洗濯機にもプログラムが組み込まれています。

最終的に、どんなプログラムを作れるようになりたいかで、適した学び方が変わってきます。

プログラミング初心者が、システム開発を学びやすく、すぐにプログラムの効果を実感しやすいのは、「業務システム」です。

業務システムの中でも、システム開発上達のコツは、ズバリ！「売上伝票」です。

そこで、当システム開発実戦講座では、以下のような売上伝票をシステム化する過程で、システム開発の基礎を学習します。

・売上伝票


この売上伝票がわかれば、業務システムが全てわかるようになる、といっても過言ではありません。

売上伝票で身に付けて欲しいポイントは以下の通りです。
・伝票と明細の関係
・テーブル設計
・テーブルの正規化
・演算フィールド

売上伝票には、あらゆる分野の基礎が含まれています。売上伝票のテーブル設計や正規化の考え方は、他の業務システムにも応用することができます。

実は、複雑そうなネットショップも、売上伝票の延長線上にあります。よく考えると、ネットショップも商品やサービスを販売しているわけですから、当然ですよね。

テーブル数や入力するデータの項目は多くなりますが、基本部分は売上伝票そのものです。

つまり売上伝票が理解できれば、ネットショップも理解できるということです。

また、まったくの初心者が、システム開発を学ぶ場合、最初に売上伝票を学ぶと、その後の上達が驚くほど早く、他の業務システムもすぐに理解できるようになります。

一見遠回りのように思えますが、売上伝票はシステム開発を習得する近道なのです。


【補足】
もし、あなたが作りたいシステムが明確なら、それを作るのが一番です。または、あなたの職場の人が希望するシステムを、作ってあげるのも良いでしょう。

身近な人に頼んで、練習台になってもらうのです。すると人の意見を聞く(取り入れる)ことの練習にもなります。人の話をしっかり聞くことは、プログラマーや、特にSEには必要な能力です。

でも作りたいシステムが、まだはっきり決まっていないのなら、「売上伝票」が一番良い教材だと思います。

]]> Step1・どんなシステムを作るか mslab blog:https://blog.seesaa.jp,syspg/111002988 http://system.pgtop.net/article/110507778.html Mon, 01 Dec 2008 13:41:31 +0900 システム開発 では、システムを運用していくうちに、様々な改善点が出てきます。例えば、前回までにテーブル設計を考えた、図書館の貸出履歴システムでは、「同じ利用者が一度に何冊も本を借りる場合」が、容易に予想できます。(1)すると、貸出日と利用者CDが、重複する可能性のあることがわかります。重複するデータは、別テーブルに分けることを検討するのが基本だと、前に説明しましたね。(2)本来なら、以下の様な形式のほうが、無駄がありません。(3)そのためには、貸出履歴テーブルを、さらに正規化.. 重複するデータは、別テーブルに分けることを検討するのが基本だと、前に説明しましたね。 (2)本来なら、以下の様な形式のほうが、無駄がありません。 (3)そのためには、貸出履歴テーブルを、さらに正規化して、2つのテーブルに分ける必要があります。 ・貸出No、貸出日、利用者CDで1つのテーブルにする ・書籍CDは複数あるので、明細として別のテーブルに分ける しかしこのままでは、貸出履歴テーブルと明細テーブルに関連性がありません。また明細テーブルにも、主キーとなるフィールドが必要です。 そこで、最終的には以下のようなテーブルに分けます。 ・貸出No(主キー)、貸出日、利用者CD(外部キー) ・明細CD(主キー)、貸出No(外部キー)、書籍CD(外部キー) このような考え方は、後に学ぶ「売上伝票」を参考にすると、よく理解できます。 実は、まだまだ他にも改善点があります。 例えば、同じタイトルの本が複数冊ある場合も考えられます。これはレンタルビデオでも同じです。人気のある映画なら、同じタイトルのビデオが、たくさん入荷することはよくありますよね。 でも、今回はデータベースの基礎編なので、これくらいにしておきます。 もっと本格的なテーブル設計については、次の「売上伝票」で学ぶことにします。 ]]> システム開発 では、システムを運用していくうちに、様々な改善点が出てきます。

例えば、前回までにテーブル設計を考えた、図書館の貸出履歴システムでは、「同じ利用者が一度に何冊も本を借りる場合」が、容易に予想できます。

(1)すると、貸出日と利用者CDが、重複する可能性のあることがわかります。



重複するデータは、別テーブルに分けることを検討するのが基本だと、前に説明しましたね。


(2)本来なら、以下の様な形式のほうが、無駄がありません。




(3)そのためには、貸出履歴テーブルを、さらに正規化して、2つのテーブルに分ける必要があります。



・貸出No、貸出日、利用者CDで1つのテーブルにする
・書籍CDは複数あるので、明細として別のテーブルに分ける

しかしこのままでは、貸出履歴テーブルと明細テーブルに関連性がありません。また明細テーブルにも、主キーとなるフィールドが必要です。

そこで、最終的には以下のようなテーブルに分けます。
・貸出No(主キー)、貸出日、利用者CD(外部キー)
・明細CD(主キー)、貸出No(外部キー)、書籍CD(外部キー)

このような考え方は、後に学ぶ「売上伝票」を参考にすると、よく理解できます。

実は、まだまだ他にも改善点があります。

例えば、同じタイトルの本が複数冊ある場合も考えられます。これはレンタルビデオでも同じです。人気のある映画なら、同じタイトルのビデオが、たくさん入荷することはよくありますよね。

でも、今回はデータベースの基礎編なので、これくらいにしておきます。

もっと本格的なテーブル設計については、次の「売上伝票」で学ぶことにします。

]]> システムを改善する mslab blog:https://blog.seesaa.jp,syspg/110507778 http://system.pgtop.net/article/110502312.html Mon, 01 Dec 2008 10:53:54 +0900 システム開発 では、どんなリレーショナルデータベースやプログラミング言語を使うことになっても、テーブル設計についての「考え方」は同じです。これまでの各テーブルの関係をまとめると、以下の図のようになります。・全体図(図書館の貸出履歴システム)生年月日のフィールドを追加したことで、いろんな集計ができるようになりましたね。大事なポイントですが、ここまでは「考え方」の部分なので、データベースの種類は、関係ありません。テーブルの作成方法を省略していたのは、そのためです。テーブルの大まか.. 生年月日のフィールドを追加したことで、いろんな集計ができるようになりましたね。 大事なポイントですが、ここまでは「考え方」の部分なので、データベースの種類は、関係ありません。テーブルの作成方法を省略していたのは、そのためです。 テーブルの大まかな設計が出来たら、あとはリレーショナルデータベースの種類によって、フィールドのデータ型を考えて、実際にテーブルを作成するだけです。 データ型は、保存するデータの種類によって、数値型、文字列型(テキスト型)、日付/時刻型などを決めます。また、数値型の場合は桁数、文字列型の場合は文字数なども考慮します。 テーブルの作成方法は、データベースによって異なります。 例えば、Microsoft Access でテーブルを作成する場合は、以下の図のようになります。 上がテーブルのデザイン画面で、下がデータを入力した画面です。 ・T貸出履歴 ＊鍵のマークは主キーであることを表します。 ・T利用者 ・T性別 ・T書籍 ・T著者 ・T出版社 【解説】 テーブル名は自由に付けることができます。「T」は接頭辞で、テーブルであることを示しています。テーブル名に番号を加えることもよくあります。 ]]> システム開発 では、どんなリレーショナルデータベースやプログラミング言語を使うことになっても、テーブル設計についての「考え方」は同じです。

これまでの各テーブルの関係をまとめると、以下の図のようになります。

・全体図(図書館の貸出履歴システム)


生年月日のフィールドを追加したことで、いろんな集計ができるようになりましたね。

大事なポイントですが、ここまでは「考え方」の部分なので、データベースの種類は、関係ありません。テーブルの作成方法を省略していたのは、そのためです。

テーブルの大まかな設計が出来たら、あとはリレーショナルデータベースの種類によって、フィールドのデータ型を考えて、実際にテーブルを作成するだけです。

データ型は、保存するデータの種類によって、数値型、文字列型(テキスト型)、日付/時刻型などを決めます。また、数値型の場合は桁数、文字列型の場合は文字数なども考慮します。

テーブルの作成方法は、データベースによって異なります。

例えば、Microsoft Access でテーブルを作成する場合は、以下の図のようになります。
上がテーブルのデザイン画面で、下がデータを入力した画面です。

・T貸出履歴


＊鍵のマークは主キーであることを表します。


・T利用者



・T性別



・T書籍



・T著者



・T出版社



【解説】
テーブル名は自由に付けることができます。「T」は接頭辞で、テーブルであることを示しています。テーブル名に番号を加えることもよくあります。

]]> テーブルを作成する方法 mslab blog:https://blog.seesaa.jp,syspg/110502312 http://system.pgtop.net/article/109929870.html Thu, 20 Nov 2008 10:20:10 +0900 システム開発 では、生年月日から年齢が計算できるようになると、いろんな集計に応用できます。例えば、図書館の貸出履歴と利用者のテーブルから、「年代別貸出数」のような集計を出力することが可能です。・年代別貸出数それでは、生年月日から年代別の集計をするまでの方法を、段階を追って考えてみましょう。【1】前回、年齢や満年齢を計算で出しました。計算に使える関数は、データベースによって異なります。この段階では、詳しい計算式は分からなくてもかまわないので、大まかなイメージだけ掴んでください。.. それでは、生年月日から年代別の集計をするまでの方法を、段階を追って考えてみましょう。 【1】前回、年齢や満年齢を計算で出しました。 計算に使える関数は、データベースによって異なります。この段階では、詳しい計算式は分からなくてもかまわないので、大まかなイメージだけ掴んでください。 年齢は現在の西暦から、生年月日の年を引けば、簡単に計算できます。 しかし、満年齢を出すには、現在の日付が、「誕生日未満」か「誕生日以降」かまで、考慮する必要がありました。 【2】年齢や満年齢が出せれば、年代を表示することは簡単です。1の位を切り捨てるだけです。 ＊10歳未満は 0 とします。 【3】年代が表示できれば、貸出履歴のデータに、利用者の年代を加えて表示することは可能です。 【4】この段階まで来ると、あとは年代をカウントするだけで、集計することができます。 ・年代別貸出数 ＊最初の図と同じです 【解説】 利用者テーブルに保存するデータは、「生年月日」だけです。生年月日があれば、いろんな計算ができます。 生年月日 → 年齢(または満年齢) → 年代 → 集計 生年月日から直接年代を計算するのは、難しく感じるので、段階を追って計算しました。 このように、リレーショナルデータベースでは、あるフィールド(列)のデータを加工することで、様々な利用ができるようになります。 どんなデータを保存しておいて、どんな処理(計算)を行なえば、どんな出力(帳票など)が得られるのか、イメージする力が必要になります。 ]]> システム開発 では、生年月日から年齢が計算できるようになると、いろんな集計に応用できます。

例えば、図書館の貸出履歴と利用者のテーブルから、「年代別貸出数」のような集計を出力することが可能です。

・年代別貸出数



それでは、生年月日から年代別の集計をするまでの方法を、段階を追って考えてみましょう。

【1】前回、年齢や満年齢を計算で出しました。



計算に使える関数は、データベースによって異なります。この段階では、詳しい計算式は分からなくてもかまわないので、大まかなイメージだけ掴んでください。

年齢は現在の西暦から、生年月日の年を引けば、簡単に計算できます。

しかし、満年齢を出すには、現在の日付が、「誕生日未満」か「誕生日以降」かまで、考慮する必要がありました。


【2】年齢や満年齢が出せれば、年代を表示することは簡単です。1の位を切り捨てるだけです。



＊10歳未満は 0 とします。


【3】年代が表示できれば、貸出履歴のデータに、利用者の年代を加えて表示することは可能です。




【4】この段階まで来ると、あとは年代をカウントするだけで、集計することができます。

・年代別貸出数


＊最初の図と同じです


【解説】
利用者テーブルに保存するデータは、「生年月日」だけです。生年月日があれば、いろんな計算ができます。

生年月日 → 年齢(または満年齢) → 年代 → 集計

生年月日から直接年代を計算するのは、難しく感じるので、段階を追って計算しました。

このように、リレーショナルデータベースでは、あるフィールド(列)のデータを加工することで、様々な利用ができるようになります。

どんなデータを保存しておいて、どんな処理(計算)を行なえば、どんな出力(帳票など)が得られるのか、イメージする力が必要になります。

]]> 年代別の集計をする方法 mslab blog:https://blog.seesaa.jp,syspg/109929870 http://system.pgtop.net/article/109888946.html Wed, 19 Nov 2008 11:18:43 +0900 システム開発 では、年齢を計算して表示することがよくあります。そこで今回は、図書館の利用者の年齢を表示してみましょう。利用者テーブルに、どんなフィールド(列)を追加すると、年齢を表示することができるか、考えてみてください。一番簡単に思い付くのは、「年齢」のフィールドを追加することです。しかし年齢は、時間が経てば変化します。リレーショナルデータベースでは、基本的に、計算して出せるデータは、テーブルに保存しません。クエリやSQLを使って、計算して表示します。ではどんなデータがあれ.. しかし年齢は、時間が経てば変化します。 リレーショナルデータベースでは、基本的に、計算して出せるデータは、テーブルに保存しません。クエリやSQLを使って、計算して表示します。 ではどんなデータがあれば、年齢が計算できるでしょうか？ そうですね。利用者の生年月日がわかれば、年齢は計算して出すことができます。したがって、利用者テーブルに追加するフィールドは、「生年月日」ということになります。 あとはクエリやSQLを使って、仮想テーブルを作成し、演算フィールドで年齢を表示することができます。 現在の年から誕生日の年を引けば、簡単に計算できますね。 このような計算をするフィールドを、「演算フィールド」といいます。演算フィールドを使うことで、テーブルに無いフィールドを表示することができます。 ただし、年齢を計算する時には注意が必要です。例えば、現在の日付が 2008年11月19日 だとします。 利用者CDが 9 の「和田　恵」さんは、誕生日が12月11日なので、今年はまだ誕生日を迎えていません。西暦の年だけで単純計算すると、1歳多くなってしまいます。 したがって満年齢を計算する時は、もう少し複雑で、現在の日付が誕生日未満か以降かまで、考慮する必要があります。 でも大丈夫です。クエリやSQLでは、複雑な計算も行なうことができます。 以下は満年齢で計算した結果です。 これで今年の誕生日がまだの人の年齢も、ちゃんと表示することができました。 以上のように、リレーショナルデータベースの設計を行なう時は、出力したいデータをそのまま保存するのではなく、元になるデータと、その処理も考えて、設計する必要があります。 【ワンポイント】 今回のような計算は、「データベース側」でも「プログラム側」でもできます。 基本的に、データベース側でできることはデータベースで行い、プログラム側では、処理結果を受け取って利用します。 そのほうがプログラムが短くて済むので、ソースコードがシンプルになります。もちろんシステム開発の効率もアップします。 ]]> システム開発 では、年齢を計算して表示することがよくあります。

そこで今回は、図書館の利用者の年齢を表示してみましょう。

利用者テーブルに、どんなフィールド(列)を追加すると、年齢を表示することができるか、考えてみてください。

一番簡単に思い付くのは、「年齢」のフィールドを追加することです。



しかし年齢は、時間が経てば変化します。

リレーショナルデータベースでは、基本的に、計算して出せるデータは、テーブルに保存しません。クエリやSQLを使って、計算して表示します。

ではどんなデータがあれば、年齢が計算できるでしょうか？

そうですね。利用者の生年月日がわかれば、年齢は計算して出すことができます。したがって、利用者テーブルに追加するフィールドは、「生年月日」ということになります。



あとはクエリやSQLを使って、仮想テーブルを作成し、演算フィールドで年齢を表示することができます。



現在の年から誕生日の年を引けば、簡単に計算できますね。

このような計算をするフィールドを、「演算フィールド」といいます。演算フィールドを使うことで、テーブルに無いフィールドを表示することができます。

ただし、年齢を計算する時には注意が必要です。例えば、現在の日付が 2008年11月19日 だとします。

利用者CDが 9 の「和田　恵」さんは、誕生日が12月11日なので、今年はまだ誕生日を迎えていません。西暦の年だけで単純計算すると、1歳多くなってしまいます。



したがって満年齢を計算する時は、もう少し複雑で、現在の日付が誕生日未満か以降かまで、考慮する必要があります。

でも大丈夫です。クエリやSQLでは、複雑な計算も行なうことができます。

以下は満年齢で計算した結果です。


これで今年の誕生日がまだの人の年齢も、ちゃんと表示することができました。


以上のように、リレーショナルデータベースの設計を行なう時は、出力したいデータをそのまま保存するのではなく、元になるデータと、その処理も考えて、設計する必要があります。


【ワンポイント】
今回のような計算は、「データベース側」でも「プログラム側」でもできます。

基本的に、データベース側でできることはデータベースで行い、プログラム側では、処理結果を受け取って利用します。

そのほうがプログラムが短くて済むので、ソースコードがシンプルになります。もちろんシステム開発の効率もアップします。

]]> 年齢を計算する方法 mslab blog:https://blog.seesaa.jp,syspg/109888946 http://system.pgtop.net/article/109800190.html Mon, 17 Nov 2008 16:31:57 +0900 システム開発 では、データベースの設計が上手くいっていると、プログラミングもスムーズに進みます。前回、テーブル設計を見直したことで、「利用者」と「書籍」の両テーブルに、データが繰り返し入力されるフィールドができました。そこで今回は、正規化の復習を兼ねて、もう一度考えてみましょう。どんなテーブルに分けて、どのようにフィールドを変更すれば、テーブルを正規化できるでしょうか。ヒントは、テーブルにまとめる時のコツと同じで、「繰り返し入力する可能性のあるものは、別のテーブルに分ける」こ.. 【2】書籍テーブルでは、「著者」と「出版社」は同じデータが入力される可能性があります。 ・同じ著者が、何冊も本を書くことがある ・同じ出版社から、たくさんの本が出版される 今回はレコード数が少ないので、実際には重複していませんが、「重複する可能性」があるなら、別のテーブルにすることを検討します。 それでは実際にテーブルを正規化してみましょう。 【3】性別は別のテーブルに分け、性別CDで参照できるようにします。 【4】著者と出版社も別のテーブルに分け、それぞれ CD で参照できるようにします。 【5】貸出履歴テーブルに変更はありません。 ・貸出履歴 これでテーブルの正規化が完了しました。 テーブルを正規化することで、同じデータを何度も入力する手間が省け、入力ミスも防げます。また保存時の容量も少なくて済みます。 【解説】 最終的な各テーブルの関係をまとめると、以下の図のようになります。 この図の関係がわかれば、リレーショナルデータベースを理解することができます。掴んで欲しいポイントを以下にまとめます。 (1)「貸出履歴」テーブルがメインで、他のテーブルは、データを参照するために使われています。 (2)利用者や書籍のテーブルからも、さらに他のテーブルを参照している点に注目してください。 (3)貸出履歴テーブルの利用者CDを変更するだけで、氏名や性別は、自動的に変わります。CD が変われば、参照するデータが変わるわけですから、当然ですよね。 (4)同様に、貸出履歴テーブルの書籍CDを変更すると、タイトルや著者、出版社が自動的に変わります。 (5)逆に、利用者テーブルの変更点や、書籍テーブルの変更点は、すぐにクエリに反映されます。貸出履歴テーブル側では、何も変更する必要はありません。 つまり、利用者の氏名の修正や、書籍のタイトルの修正は、一箇所だけで済むということです。 ]]> システム開発 では、データベースの設計が上手くいっていると、プログラミングもスムーズに進みます。

前回、テーブル設計を見直したことで、「利用者」と「書籍」の両テーブルに、データが繰り返し入力されるフィールドができました。

そこで今回は、正規化の復習を兼ねて、もう一度考えてみましょう。

どんなテーブルに分けて、どのようにフィールドを変更すれば、テーブルを正規化できるでしょうか。

ヒントは、テーブルにまとめる時のコツと同じで、
「繰り返し入力する可能性のあるものは、別のテーブルに分ける」
ことです。


【1】利用者テーブルでは、「性別」が繰り返し入力されています。




【2】書籍テーブルでは、「著者」と「出版社」は同じデータが入力される可能性があります。



・同じ著者が、何冊も本を書くことがある
・同じ出版社から、たくさんの本が出版される

今回はレコード数が少ないので、実際には重複していませんが、「重複する可能性」があるなら、別のテーブルにすることを検討します。


それでは実際にテーブルを正規化してみましょう。

【3】性別は別のテーブルに分け、性別CDで参照できるようにします。




【4】著者と出版社も別のテーブルに分け、それぞれ CD で参照できるようにします。




【5】貸出履歴テーブルに変更はありません。

・貸出履歴


これでテーブルの正規化が完了しました。

テーブルを正規化することで、同じデータを何度も入力する手間が省け、入力ミスも防げます。また保存時の容量も少なくて済みます。


【解説】
最終的な各テーブルの関係をまとめると、以下の図のようになります。



この図の関係がわかれば、リレーショナルデータベースを理解することができます。掴んで欲しいポイントを以下にまとめます。

(1)「貸出履歴」テーブルがメインで、他のテーブルは、データを参照するために使われています。

(2)利用者や書籍のテーブルからも、さらに他のテーブルを参照している点に注目してください。

(3)貸出履歴テーブルの利用者CDを変更するだけで、氏名や性別は、自動的に変わります。CD が変われば、参照するデータが変わるわけですから、当然ですよね。

(4)同様に、貸出履歴テーブルの書籍CDを変更すると、タイトルや著者、出版社が自動的に変わります。

(5)逆に、利用者テーブルの変更点や、書籍テーブルの変更点は、すぐにクエリに反映されます。貸出履歴テーブル側では、何も変更する必要はありません。

つまり、利用者の氏名の修正や、書籍のタイトルの修正は、一箇所だけで済むということです。

]]> さらにテーブルを正規化する mslab blog:https://blog.seesaa.jp,syspg/109800190 http://system.pgtop.net/article/109785340.html Mon, 17 Nov 2008 10:19:36 +0900 システム開発 で、リレーショナルデータベースのテーブルを設計する時には、元々紙の帳票には無かった部分まで、考える必要があります。通常、業務システムの流れは、以下のようになります。入力画面 → 処理 → 出力画面(または帳票)前回は「入力画面」を中心に、テーブル設計を考えました。前回までのテーブル設計でも、図書館の「貸出履歴」をシステム化するという、最低限の目的は達成できます。しかし、データは蓄積するだけでは意味が無く、加工したり、集計することで、はじめて活きてきます。そこで今.. 【3】次は書籍側のテーブルです。 著者ランキングは、「著者」フィールドがあれば可能です。出版社ランキングも「出版社」のフィールドがあればよいことになります。 また、書籍の購入にかかった費用として、本の総額を出したい場合は、「価格」のフィールドを用意しておけば問題ありません。 ・書籍 【4】貸出履歴のテーブルは、前回と同じです。変更点は何もありません。 ・貸出履歴 【5】フィールド数を増やしたことで、さらに詳細なデータを参照できるようになりました。 【6】複数のテーブルから、目的に合わせて、仮想テーブルを作成することもできます。 ここまで来ると、データをカウントすることが出来ます。 また、表示するフィールドは、自由に選択できるため、不要なフィールドは、表示しなければよいだけです。 このようなことが簡単にできることも、リレーショナルデータベースのメリットです。 【7】あとはクエリやSQLで集計すれば、目的の帳票を出力できます。 ・男女別貸出数 ・著者ランキング ・出版社ランキング ・本の総額 ＊貸出履歴のデータが少ないため、ランキングは同数になっていますが、データ数が増えれば、ちゃんと順位ごとに並べることができます。 また、クエリやSQLについては、ここでは説明を省きます。詳しくは以下の講座をご覧ください。 ・Microsoft Access初心者入門講座 ・Access SQL初心者入門講座 これでとりあえず集計できるようになりました。でもこの状態のテーブルでは、十分とは言えません。 既に気付いている人もいると思いますが、今回の変更で、「利用者」、「書籍」の両テーブルに、データが繰り返し入力されるフィールドができました。 したがって、さらにテーブルを正規化する必要があります。 正規化の続きは次回に解説しますが、自身のある人は、自分でも考えてみてください。どのようなテーブルを追加するとよいのでしょうか。 ]]> システム開発 で、リレーショナルデータベースのテーブルを設計する時には、元々紙の帳票には無かった部分まで、考える必要があります。

通常、業務システムの流れは、以下のようになります。
入力画面 → 処理 → 出力画面(または帳票)

前回は「入力画面」を中心に、テーブル設計を考えました。

前回までのテーブル設計でも、図書館の「貸出履歴」をシステム化するという、最低限の目的は達成できます。

しかし、データは蓄積するだけでは意味が無く、加工したり、集計することで、はじめて活きてきます。

そこで今回は、「処理」や「出力画面」も考慮して、テーブルの設計を見直してみましょう。

【1】例えば、貸出履歴のデータから、以下の帳票を出力したいとします。
・男女別貸出数
・著者ランキング
・出版社ランキング
・本の総額

そうなると、これまで無かったフィールド(列)も考える必要があります。

ポイントは、目的の出力を得るためには、どんなデータを、どう処理すれば実現できるか、考えることです。


【2】まず利用者側のテーブルを考えます。

男女別貸出数は、「性別」のフィールドを加えるだけで、集計できます。

・利用者



【3】次は書籍側のテーブルです。

著者ランキングは、「著者」フィールドがあれば可能です。出版社ランキングも「出版社」のフィールドがあればよいことになります。

また、書籍の購入にかかった費用として、本の総額を出したい場合は、「価格」のフィールドを用意しておけば問題ありません。

・書籍



【4】貸出履歴のテーブルは、前回と同じです。変更点は何もありません。

・貸出履歴



【5】フィールド数を増やしたことで、さらに詳細なデータを参照できるようになりました。




【6】複数のテーブルから、目的に合わせて、仮想テーブルを作成することもできます。



ここまで来ると、データをカウントすることが出来ます。

また、表示するフィールドは、自由に選択できるため、不要なフィールドは、表示しなければよいだけです。

このようなことが簡単にできることも、リレーショナルデータベースのメリットです。


【7】あとはクエリやSQLで集計すれば、目的の帳票を出力できます。

・男女別貸出数


・著者ランキング


・出版社ランキング


・本の総額


＊貸出履歴のデータが少ないため、ランキングは同数になっていますが、データ数が増えれば、ちゃんと順位ごとに並べることができます。

また、クエリやSQLについては、ここでは説明を省きます。詳しくは以下の講座をご覧ください。
・Microsoft Access初心者入門講座
・Access SQL初心者入門講座


これでとりあえず集計できるようになりました。でもこの状態のテーブルでは、十分とは言えません。

既に気付いている人もいると思いますが、今回の変更で、「利用者」、「書籍」の両テーブルに、データが繰り返し入力されるフィールドができました。

したがって、さらにテーブルを正規化する必要があります。

正規化の続きは次回に解説しますが、自身のある人は、自分でも考えてみてください。どのようなテーブルを追加するとよいのでしょうか。

]]> 帳票からテーブル設計を見直す mslab blog:https://blog.seesaa.jp,syspg/109785340 http://system.pgtop.net/article/109605317.html Thu, 13 Nov 2008 10:52:47 +0900 システム開発 で利用される、リレーショナルデータベースについて、理解を深めるため、簡単な例題で説明します。今回は、図書館の「貸出履歴」をシステム化する場合を考えてみましょう。リレーショナルデータベースの学習用に、システムをかなり簡略化しています。今まで紙の書類で行なっていた業務を、パソコンを使ってシステム化する時、表計算ソフトを使う方法と、データベースソフトを使う方法が考えられます。例えば Excel のような表計算ソフトでは、以下のようになります。Excel のメリットは、.. Excel のメリットは、紙の書類の形式を、そのままパソコン上に表現しやすいことです。そのため初心者でも、比較的簡単に扱うことができます。 Access のようなデータベースソフトでも、上の図のように、一つのテーブルで管理することは出来ます。 しかし、リレーショナルデータベースでは、データは意味のあるグループごとに、テーブルにまとめるのが一般的です。 テーブルにまとめるコツは、「繰り返し入力する可能性のあるものは、別のテーブルに分ける」ということです。 ＊ただし日付は除く それでは、実際に行なってみましょう。 【1】今回の例では、利用者の氏名や、書籍のタイトルが、何度も繰り返し入力されています。 何故なら、同じ人が何度も本を借りることがあるし、同じ本が何度も借りられることがあるからです。 【2】そこで、利用者と書籍を、別のテーブルに分けてみましょう。 ・利用者 ・書籍 【3】すると、貸出を記録するテーブルは、以下のように、数字の並びだけで済むようになります。 ・貸出履歴 このような作業を「正規化」と言います。 文字列を入力したり、コピー＆ペーストするよりは、数字だけを入力したほうが、入力ミスが減らせます。 また文字列より数字のほうが、ハードディスクに保存する時の容量が少なくて済むというメリットがあります。 【4】貸出履歴テーブルには、利用者CD と書籍CD しかありませんが、必要な時に、他のテーブルを参照することで、データがわかります。 ・赤丸　利用者CD が「1」の人は「田中　愛」さんだとわかる。 ・青丸　書籍CD が「3」の本は「村上式シンプル英語勉強法」だとわかる。 【5】また、複数のテーブルから、目的に合わせて、仮想テーブルを作成することもできます。 このように、リレーショナルデータベースでは、関連するデータごとにテーブルに分けて、必要な時に組み立てて利用します。 一見、表計算ソフトより複雑ですが、扱うデータ数が多くなるほど、データベースのメリットが出てきます。 【解説】 (1)貸出No、利用者CD、書籍CD などは、「主キー」と呼ばれています。主キーとは、データベースの中から、レコードを「一意」に識別するためのものです。 ＊主キー(primary key) 一意とは同じデータが他に無く、重複しないことです。主キーを設定したフィールド(列)には、同じデータを入力できません。 したがって、利用者テーブルの主キーである利用者CD が「1」の人は、確実に「田中　愛」さんだと識別できるわけです。 たとえ同姓同名の人がいても、利用者CD が「1」の人は、必ず1人しかいません。 同様に、貸出履歴テーブルでも、それぞれのレコードを識別するために、主キーが必要なので、「貸出No」のフィールド(列)を追加しました。 これで、同じ日に、同じ人が、同じ本を借りても、履歴を識別できます。 ちなみに、貸出履歴テーブル側にある 利用者CD と 書籍CD は、外部キーといい、データを参照するために使われるフィールドです。 ＊外部キー(Foreign Key) フィールド名は同じですが、どのテーブルにあるかによって、役割が変わり、呼び方が変わるわけです。(フィールド名は異なってもかまいません) (2)リレーショナルデータベースでは、利用者テーブル側に無い「利用者CD」を、貸出履歴テーブル側で入力できないようにするなど、「制約」を設定することができます。 制約を設定しておけば、矛盾したデータが入力されるのを防ぐことができます。 実際のシステムでは、データをコンボボックスから選択するような方法になるので、さらに入力ミスが防げます。 ・コンボボックス ＊コンボボックスの機能は、プログラミング言語側で実現します。 データベースには、システムを安全に運用できる機能が、他にもいろいろ用意されています。 ]]> システム開発 で利用される、リレーショナルデータベースについて、理解を深めるため、簡単な例題で説明します。

今回は、図書館の「貸出履歴」をシステム化する場合を考えてみましょう。

リレーショナルデータベースの学習用に、システムをかなり簡略化しています。

今まで紙の書類で行なっていた業務を、パソコンを使ってシステム化する時、表計算ソフトを使う方法と、データベースソフトを使う方法が考えられます。

例えば Excel のような表計算ソフトでは、以下のようになります。


Excel のメリットは、紙の書類の形式を、そのままパソコン上に表現しやすいことです。そのため初心者でも、比較的簡単に扱うことができます。

Access のようなデータベースソフトでも、上の図のように、一つのテーブルで管理することは出来ます。

しかし、リレーショナルデータベースでは、データは意味のあるグループごとに、テーブルにまとめるのが一般的です。

テーブルにまとめるコツは、「繰り返し入力する可能性のあるものは、別のテーブルに分ける」ということです。

＊ただし日付は除く


それでは、実際に行なってみましょう。


【1】今回の例では、利用者の氏名や、書籍のタイトルが、何度も繰り返し入力されています。



何故なら、同じ人が何度も本を借りることがあるし、同じ本が何度も借りられることがあるからです。


【2】そこで、利用者と書籍を、別のテーブルに分けてみましょう。

・利用者


・書籍



【3】すると、貸出を記録するテーブルは、以下のように、数字の並びだけで済むようになります。

・貸出履歴


このような作業を「正規化」と言います。

文字列を入力したり、コピー＆ペーストするよりは、数字だけを入力したほうが、入力ミスが減らせます。

また文字列より数字のほうが、ハードディスクに保存する時の容量が少なくて済むというメリットがあります。


【4】貸出履歴テーブルには、利用者CD と書籍CD しかありませんが、必要な時に、他のテーブルを参照することで、データがわかります。



・赤丸　利用者CD が「1」の人は「田中　愛」さんだとわかる。
・青丸　書籍CD が「3」の本は「村上式シンプル英語勉強法」だとわかる。


【5】また、複数のテーブルから、目的に合わせて、仮想テーブルを作成することもできます。



このように、リレーショナルデータベースでは、関連するデータごとにテーブルに分けて、必要な時に組み立てて利用します。

一見、表計算ソフトより複雑ですが、扱うデータ数が多くなるほど、データベースのメリットが出てきます。


【解説】
(1)貸出No、利用者CD、書籍CD などは、「主キー」と呼ばれています。主キーとは、データベースの中から、レコードを「一意」に識別するためのものです。

＊主キー(primary key)

一意とは同じデータが他に無く、重複しないことです。主キーを設定したフィールド(列)には、同じデータを入力できません。

したがって、利用者テーブルの主キーである利用者CD が「1」の人は、確実に「田中　愛」さんだと識別できるわけです。

たとえ同姓同名の人がいても、利用者CD が「1」の人は、必ず1人しかいません。

同様に、貸出履歴テーブルでも、それぞれのレコードを識別するために、主キーが必要なので、「貸出No」のフィールド(列)を追加しました。



これで、同じ日に、同じ人が、同じ本を借りても、履歴を識別できます。

ちなみに、貸出履歴テーブル側にある 利用者CD と 書籍CD は、外部キーといい、データを参照するために使われるフィールドです。

＊外部キー(Foreign Key)

フィールド名は同じですが、どのテーブルにあるかによって、役割が変わり、呼び方が変わるわけです。(フィールド名は異なってもかまいません)


(2)リレーショナルデータベースでは、利用者テーブル側に無い「利用者CD」を、貸出履歴テーブル側で入力できないようにするなど、「制約」を設定することができます。

制約を設定しておけば、矛盾したデータが入力されるのを防ぐことができます。

実際のシステムでは、データをコンボボックスから選択するような方法になるので、さらに入力ミスが防げます。

・コンボボックス


＊コンボボックスの機能は、プログラミング言語側で実現します。

データベースには、システムを安全に運用できる機能が、他にもいろいろ用意されています。

]]> テーブルの正規化について学ぶ mslab blog:https://blog.seesaa.jp,syspg/109605317