【发布时间】:2016-04-13 01:11:28
【问题描述】:
这是一个示例问题,我们必须为...构建 ER 图/关系...我正在为关系是什么而苦苦挣扎!
公司的所有电脑都有序列号。此外,它们还有购买日期、制造商和操作系统版本。一些计算机是具有上述列的服务器以及静态 IP 地址和服务器管理员。非服务器的计算机称为工作站。他们在有指定房间号的办公室。
请帮忙:)
【问题讨论】:
标签: sql entity-relationship diagram
这是一个示例问题,我们必须为...构建 ER 图/关系...我正在为关系是什么而苦苦挣扎!
公司的所有电脑都有序列号。此外,它们还有购买日期、制造商和操作系统版本。一些计算机是具有上述列的服务器以及静态 IP 地址和服务器管理员。非服务器的计算机称为工作站。他们在有指定房间号的办公室。
请帮忙:)
【问题讨论】:
标签: sql entity-relationship diagram
为了使您的数据库完全规范化,您需要使用 1:0..1 关系:
CREATE TABLE computer {
serial_number varchar,
purchase_date date,
manufacturer varchar,
os_version varchar,
computer_type varchar(1), 'server or workstation
PRIMARY KEY (serial_number)
}
CREATE TABLE computer_server {
serial_number varchar,
static_ip varchar,
admin varchar,
PRIMARY KEY (serial_number),
CONSTRAINT fk_computer_server FOREIGN KEY (serial_number) REFERENCES computer(serial_number)
}
CREATE TABLE computer_workstation {
serial_number varchar,
room_number int,
PRIMARY KEY (serial_number),
CONSTRAINT fk_computer_workstation FOREIGN KEY (serial_number) REFERENCES computer(serial_number)
}
【讨论】:
subtyping。服务器和工作站是计算机的子类型,计算机是超类型。 OO 类最适合用封装数据对状态机建模,而不是对数据本身建模,因为对象仅支持二进制定向关系和固定访问路径。此外,3NF 肯定不是理想的解决方案,它会受到许多数据异常的影响。它之所以流行只是因为 ER 并且因为多值依赖关系很难理解。
首先,弄清楚“实体”是什么。
实体是一个人、地点、事物、概念或事件,它 1) 可以被唯一标识 2) 对业务很重要,以及 3) 我们想要存储有关信息。
查看规格,并取出任何看起来可能是实体的东西。这些可能不都是实体,但它们是我们在开发模型时考虑的候选对象。
一旦我们有了候选实体的列表,我们就会提出适当的问题来找出它们之间的关系。
让我们从“办公室”和“工作站”开始。那里有关系吗?让我们对它说几句话……我们可能不知道正确的词,但我们可以试一试。由于缺乏更好的东西,让我们尝试......
现在,我们需要提出一些适当的问题,以确定关系的基数。是一对一、一对多、零还是一对多等。我们提出的问题通常是以下形式:
根据对这些问题的回答,我们确定是否需要建立这种关系...例如,工作站是否必须位于办公室中。这在我们的模型中是强制性的还是可选的?
(忽略时间数据的建模,对单个时间点的状态进行建模,我们可能会确定:
这是一对多关系的示例,其中关系是可选的。
我们的一些候选实体将不是我们模型中的实体。例如,也许计算机的“制造商”对业务并不重要,或者我们不需要存储任何信息来存储有关“购买”事件的信息。
“服务器”和“服务器管理员”的关系...
这很可能在我们的模型中变成多对多关系。 (我们可能会引入一个额外的“administrates”表来解决多对多关系,其中新的“administrates”关系表将与“server”和“server admin”都有外键关系。
【讨论】: