設計図を基にAccessでテーブルを作っていきます。

「作成」タブのテーブルをクリックすると下の画面が表示されます。
続きを読む →

もう少し理解を深めてもらうために以前例に出した日常接しているデータベースをテーブルで簡単にまとめてみました。
銀行通帳

図書館の利用履歴

続きを読む →

テーブルの作成手順
・どのようなフィールドが必要なのか？
・フィールドの設定（データ型やデータのサイズ）の決め方
などを具体的に解説します。

フィールドの決め方
テーブルを作るときに一番悩むのは、どのようなフィールドが必要になるのか？ということです。もちろん後からでも追加できるので、最初にきっちり決める必要はありません。
まずはじめにどういった情報を貯めたいのかを考えます。
続きを読む →

次に大事になるのが、「一意」という言葉。つまり「Only　One」ということです。銀行口座の場合、あってはならないことそれは同じ口座番号が二つあるということです。二つ同じ口座番号があるとどちらがAさんの取引で、どちらがBさんの取引なのかわからなくなってしまいます。これでは安心して銀行と取引することもできません。

この場合絶対に「一意」にならなければいけない情報は、「口座番号」と「ID」です。通常Accessでデータベースを作成する場合、「一意」とならなければならないフィールドを「主キー」と設定します。

では一つの取引テーブルに入力された複数の口座番号の取引をどうやって分けたらいいのでしょうか？

ここで出てくるのが「クエリ」という機能です。
続きを読む →

銀行の利用履歴を少し細かく見ています。
まず一番大事な情報は、あなたの記録です。
例えば、口座番号、支店名（店舗番号）、種別、名前、住所、印鑑
こういった情報は口座を開設するときに必要事項を記載する（名前・住所・印鑑）、銀行から一方的に与えられる（口座番号、支店番号）二種類の情報に分けられます。
これをデータとしてまとめます。

口座番号や店舗番号、種別、氏名、住所、連絡先、生年月日をデータベース用語で言うと、「フィールド」と呼びます。
そしてテーブルで構成されているデータの塊のことを「テーブル」といいます。
続きを読む →

銀行の大きなサーバーには、大きく簡単に分けると、顧客の情報とその取引明細が保存されています。

いま顧客には二人の顧客が登録されていますが、取引の明細を見てみても、どちらの取引明細なのかが分かりません。

区別するには二つの方法があります。
一つ目は顧客ごとに取引テーブルを作ることです。

顧客によってテーブルを変えて明細を蓄積していくことで誰の取引明細なのかわかります。

もう一つの方法は次のように取引テーブルを変更します。

口座番号というフィールドを取引テーブルに追加しました。これであれば取引の明細がどの口座で行われたのかがわかります。

ではどちらの方法がいいでしょうか？
最初の方法、口座ごとに取引テーブルを分ける方法だと、パっとみて一連の取引が分かるし、見やすく、発想もExcelっぽいです。ただこの方法だと口座の数がどんどん増えていった場合それに比例してテーブルの数も増えていき、管理が大変そうです。そもそも口座が増えるたびにテーブルを作らないといけないし、取引を入れるテーブルも自分で探して取引を入れないといけません。これでは膨大ではなくてもちょっとしたデータでも管理不能になるのはご理解いただけると思います。

ですので当然取られている方法は後者だと思います。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
今週は雨が多く、思った通りのトレーニングができません。
来月末には今シーズン最初のフルマラソン。
なんとか3時間走れる体に仕上げないと。

本日も最後までお読みいただきありがとうございます。

データベースと聞くと、どこかの大きな会社が使うもので自分に照らし合わせてみると、関係がなさそうに感じますが、実は皆さんの身近なところで沢山使われています。

例えば、

銀行通帳

新幹線の予約システム

図書館の利用履歴

コンビニのPOSレジ

ポイントカード

クレジットカードの利用履歴

ETC

など
続きを読む →

名刺を一覧で検索できるようにしたら、その方との活動の内容を登録し、
あとからどのような経緯で付き合いがあるのか、分かるようにします。

最初に活動記録を入れるテーブルを作ります。

IDは名刺データのIDと関連付けするために作成します。あとはタイトルがあってもいいかなと思います。
続きを読む →