今回はＤＢ上のテーブル(表)です。
データベース、特にRDBMSにおいて一番基本になるオブジェクトです。とは言っても、具体的なテーブルを作るコマンド云々の話でもありません。
取りあえず、テーブル設計の基礎の基本と言ったところでしょうか。
ユーザーの挙動を「ある仮説に基づいて」テーブルにぼんぼん放りこむことがユーザーを知る具体的なプロセスです。

「んなこと言ったって、ユーザーのことについての仮説を考えたいからWeb-DBを使いたいんじゃん。仮説がはじめにあるんだったら誰も苦労せんわい」

という方、ごもっともです。この世界では、いくつかの暗黙の了解というか、暗黙の仮説がいくつかあります。それに基づいて基本的テーブルをまず決めて行くことが重要です。まず明確な仮説を通販向けサイトを例にしていくつか。

１・Web上でのユーザーの挙動はユーザー自身の何らかの性質をあらわす。
２・商品を買うという行動は、ユーザーの性質をあらわす挙動である。
３・商品を見るという行動も、ユーザーの性質をあらわす挙動である。

小難しく書きましたが、１は要はWebでなんかやるという行動が、ユーザー自 身のなんかを表しているということ、２、３は買い物やそれに準ずる行動がユーザーを代表する物であるとみなすと決めていること。
要は、この、１、２、３をあらわすテーブルを作ることがはじめの１歩であるということです。通販じゃないと、２、３の部分がまた違う仮説が必要になります。

では、まず１をあらわすテーブルから作ります。ユーザーの基本情報のテーブルがそれに相当します。
一般にはこんな感じでしょうか。

-----列名------＋--中身--
ユーザーＩＤ　　：一意キー
ユーザー名　　　：文字列
メールアドレス　：文字列
パーミッション　：On-Off
住所　　　　　　：文字列
郵便番号　　　　：文字列
電話番号　　　　：文字列

列名というのはテーブルの要素です。
その要素がどうなっているのかというのを中身と表現しておきましょう。
ここで重要なのがユーザーＩＤという物。一意キーであるということが非常に重要です。この世にそのユーザーＩＤを持つユーザーが一人しかいないということを意味します。

次に２をあらわすテーブルを考えましょう。これは、二つのテーブルが必要になります。
ひとつは商品マスターに相当する商品自体のテーブル（商品テーブル）。
もうひとつは、度のユーザーが度の商品を買い物したかということを残すテーブル（購買履歴テーブル）が必要です。

商品テーブル
-----列名------＋--中身--
商品ＩＤ　　　　：一意キー
商品名　　　　　：文字列
仕入値　　　　　：数値
売価　　　　　　：数値
紹介文　　　　　：文字列

購買履歴テーブル
-----列名------＋--中身--
購買履歴ＩＤ　　：キー
商品ＩＤ　　　　：外部キー
ユーザーＩＤ　　：外部キー
購入日　　　　　：日付

ここで最大のポイントは、購買履歴テーブルです。
色々組み立て方はあるのですが、今回はこういう組み立て方を紹介します。
ポイントは、キーの使い方です。購買履歴ＩＤはただのキーです。
一意ではないのでいくつも同じ数字が存在します。
ただし考え方としては１回の買い物で同じキーを使います。
３つの商品を一度に購入すれば、３つの同じ購買履歴ＩＤを持ったレコード（テーブルの中身）が出来あがります。
そしてもう二つが外部キーの商品ＩＤとユーザーＩＤ。
今まで作ったテーブルの商品ＩＤとユーザーＩＤに相当します。
要するにＩＤ番号だけ指定すれば、誰が何を買ったのかが明確に決められると言うわけです。
次に３番のテーブルを作るということを続けます。これは２の問題の応用ということで今回は解答は書きません。
ただこのテーブルは、本当に基本的な仮説だけでしか出来ていませんので、サイトの発展に応じて気長に改変して行く必要があります。
ここまででようやくテーブルが出来たのですが、このテーブルの中身ってどうやって入れて行くの？ということが次に必要です。
それと同時に、このテーブルにたまった中身からどうやって情報を引き出すの？ ということも必要です。

順を追って次回は、テーブルへ中身をためる方法を解説します。また後の回で、テーブルを作る実際の作業を紹介できれば良いなと思います。----- EXTENDED BODY: