私はデータベースの設計をいじっている初心者です。従業員情報を含むデータベースを (mysql を使用して) 作成したいと考えています。次に、各従業員のプロフィールを表示する Web クライアントを作成します。これまでのところ、列は次のようになります。
1) user id
2) first name
3) last name
4) email address
5) phone number
6) fax number
7) department(which will be like a category)
最適な設計は、1 つのテーブルに項目 1 ～ 6 列を作成し、それ自体のテーブルに部門列を (id 列を使用して) 配置することでしょうか? または、すべてのアイテムを独自のテーブルにして、各テーブルに追加の id 列を作成する必要があります....これは #1 の正規化フォームですか?
どの列も多値でない限り (従業員が複数の部門を持つことができるなど)、設計は最適です。
SQLで考えている場合は、（少なくとも）最初の正規形で考えるのが得策です。複数値の列は遅いだけでなく、混乱への第一歩でもあります。Nosqlベースのソリューションに移行する場合、このルールは適用されません。
通常のフォーム2から5は、テーブルへの入力には役立ちますが、Webクライアントには役立ちません。完全な正規化から得られる最大のことは、データベースがそれ自体と矛盾しないことを保証することです。2つの異なる従業員レコード（行）にある、同じ部門の2つの異なる名前のようなもの。
ビジョンに追加する必要がある大きなことは、ビューです。ビューを使用すると、非常に効果的にデータをWebページの外観に近づけることができます。これにより、Webクライアントの構築が非常に簡単になります。ビューも役に立たない領域があります。
ドロップダウンリストを取ります。提案されているように、人々が複数の電話番号を持つことができる場合は、従業員のページに電話番号のドロップダウンリストを作成することをお勧めします。これは基本的に複数値のフィールドであり、ビューはその点で特に役立ちません。
いくつかのさらなる考え...
時間について考えることを忘れないでください。従業員は部門を変更できますか？この歴史を知りたいですか？その場合は、個別のDepartmentsテーブルと、おそらくEmployeeID、DepartmentID、StartDate、およびEndDateを持つService（または何か）テーブルが必要になります。
時間の経過とともに発生する変化について考えている間、電話番号とファックス番号、および電子メールアドレスは従業員または役職に適合していますか？アカウントのジャネットが上司の仕事に就いた場合、彼女は新しいオフィスで別の電話番号を取得しますか、それとも電話番号が人々と一緒に移動する場所の1つですか。電子メールの同上。アドレスはhr.officer@example.comまたはjoe.smith@example.comですか？前者の場合、どちらの場合も、DepartmentID外部キーを持つ電話/ファックス/電子メール（およびペイグレード、FT、PTなど）を追跡する位置テーブルについて考えたいと思うでしょう。
最初の解決策の方が優れています。項目 1 から 6 はすべて同じテーブルにある必要がありますusers。departments保存する部門に関する詳細情報がある場合は、少なくとも 2 つの列を持つ特定のテーブルが必要です。idそしてname、usersテーブルには、テーブルdepartment内の部門に対応する ID を格納する _id 列があります。 departments.
users部門に関する他の情報を保存しない場合は、ユーザーに関する情報を取得または更新するたびにテーブルを結合する必要がないように、テーブルに部門名を直接保存することをお勧めします。
User_Master
------------------
UserID - Primary Key
DeptID - Foreign Key
FirstName
LastName
EmailID
PhoneNumber
FaxNumber
Dept_Master
----------------
DeptID - PrimaryKey
DepartmentName
各部門のIDで構成される部門1、部門2などの部門列を持つことができると思います。IDと部門名を持つ部門という別のテーブルを作成できます。これで、最初のテーブルの部門 ID を 2 番目のテーブルにリンクできます。従業員が複数の部門に属している場合、これは混乱しません。