0

我是一个在设计数据库方面搞砸的新手。我想创建一个包含员工信息的数据库（使用 mysql）。然后我将编写 Web Client 来显示每个员工的个人资料。到目前为止，我的专栏是：

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-6 列在一个表中，然后将部门列放在它自己的表中（带有 id 列）？或者我应该让所有项目成为自己的表格，给每个表格一个额外的 id 列......这会是＃1规范化形式吗？

4

6 回答 6

2

只要您的列都不是多值的（例如，一个员工可以有多个部门），那么您的设计就是最优的。

于 2012-12-09T09:28:10.563 回答
1

一些进一步的想法......

不要忘记考虑时间。员工可以更换部门吗？您有兴趣了解这段历史吗？如果是这种情况，您将必须有一个单独的 Departments 表，并且可能是一个带有 EmployeeID、DepartmentID、StartDate 和 EndDate 的服务（或其他）表。

在考虑随着时间的推移发生的变化时，电话和传真号码以及电子邮件地址是否适合员工或职位？如果会计部门的珍妮特找到主管的工作，她是否会在新办公室获得不同的电话号码，或者是电话号码随人们移动的地方之一。电子邮件同上。地址是 hr.officer@example.com 还是 joe.smith@example.com？如果在这两种情况下都是前者，您可能需要考虑一个位置表，该表跟踪具有 DepartmentID 外键的电话/传真/电子邮件（以及工资等级、FT 或 PT 等）。

于 2012-12-09T09:44:01.603 回答
1

如果您正在思考 SQL，那么您肯定最好以（至少）第一范式思考。多值列不仅速度慢，而且是迈向混乱的第一步。如果您转向基于 Nosql 的解决方案，则此规则不适用。

范式 2 到 5 有助于填充表格，但不会帮助您使用 Web 客户端。您将从完全规范化中获得的最大好处是保证数据库不会自相矛盾。诸如同一部门的两个不同名称，在两个不同的员工记录（行）中。

您需要添加到您的愿景的最重要的事情是视图。您可以使用视图来获得非常好的效果，以使数据看起来更像您希望网页的外观。这将使构建 Web 客户端更加容易。有些领域的观点也无济于事。

采取下拉列表。如果按照建议，人们可以拥有多个电话号码，您可能希望在员工页面上有一个电话号码下拉列表。这基本上是一个多值字段，视图在这方面并不是特别有用。

于 2012-12-09T12:56:58.767 回答
1

您的第一个解决方案更好，项目 1 到 6 应该都在同一个表中users。如果您有更多关于部门的信息要存储，那么您需要一个特定的表，该表departments至少有两列：id然后name在users表中您将有一个_id 列，该列将存储与表中department部门对应的 id departments.

如果您不存储有关部门的任何其他信息，最好将部门名称直接存储在users表中，以避免每次检索或更新有关用户的信息时都必须加入表。

于 2012-12-09T09:28:04.710 回答
1 
User_Master
------------------

UserID - Primary Key
DeptID  - Foreign Key
FirstName
LastName
EmailID
PhoneNumber
FaxNumber


Dept_Master
----------------

DeptID - PrimaryKey
DepartmentName
于 2012-12-09T09:28:48.997 回答
0

我认为您可以拥有部门列，例如部门 1、部门 2 等，其中将包含每个部门的 ID。您可以创建另一个名为部门的表，该表将包含 ID 和部门名称。现在您可以将第一个表中的部门 ID 链接到第二个表中。如果员工属于多个部门，这不会造成混乱。

于 2012-12-09T09:33:21.770 回答