【问题标题】:ER Diagram sample- what is the relationship?ER 图示例 - 有什么关系?
【发布时间】:2016-04-13 01:11:28
【问题描述】:

这是一个示例问题,我们必须为...构建 ER 图/关系...我正在为关系是什么而苦苦挣扎!

公司的所有电脑都有序列号。此外,它们还有购买日期、制造商和操作系统版本。一些计算机是具有上述列的服务器以及静态 IP 地址和服务器管理员。非服务器的计算机称为工作站。他们在有指定房间号的办公室。

请帮忙:)

【问题讨论】:

    标签: sql entity-relationship diagram


    【解决方案1】:

    为了使您的数据库完全规范化,您需要使用 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)
    }
    

    【讨论】:

    • 谢谢先生!我完全忘记了归一化关系,doh lol
    • 什么是“规范化关系”?计算机/服务器/工作站看起来更像是一个类层次结构(服务器和工作站是计算机的子类),而不是看起来像不同实体之间的关系。 (即查看什么“唯一标识”一台计算机,以及什么“唯一标识”一台服务器。这些真的是一回事吗?)“每个子类的表”是一种可能的实现,但还有其他实现可能更好适合的,例如超类的表和子类的鉴别器列。
    • 数据库规范化(或规范化)是组织关系数据库的列(属性)和表(关系)以最小化数据冗余的过程......很像类层次结构。第三范式(3NF)通常是理想的解决方案:en.wikipedia.org/wiki/Third_normal_form
    • 如果这是正确答案,请点赞!谢谢
    • 这里的正确答案是subtyping。服务器和工作站是计算机的子类型,计算机是超类型。 OO 类最适合用封装数据对状态机建模,而不是对数据本身建模,因为对象仅支持二进制定向关系和固定访问路径。此外,3NF 肯定不是理想的解决方案,它会受到许多数据异常的影响。它之所以流行只是因为 ER 并且因为多值依赖关系很难理解。
    【解决方案2】:

    首先,弄清楚“实体”是什么。

    实体是一个人、地点、事物、概念或事件,它 1) 可以被唯一标识 2) 对业务很重要,以及 3) 我们想要存储有关信息。

    查看规格,并取出任何看起来可能是实体的东西。这些可能不都是实体,但它们是我们在开发模型时考虑的候选对象。

    • 电脑
    • 公司
    • 序列号
    • 购买(活动)
    • 制造商
    • 操作系统版本
    • 服务器
    • 静态 IP 地址(“网络”也可能是一个实体)
    • 服务器管理员(人)
    • 工作站
    • 办公室

    一旦我们有了候选实体的列表,我们就会提出适当的问题来找出它们之间的关系。

    让我们从“办公室”和“工作站”开始。那里有关系吗?让我们对它说几句话……我们可能不知道正确的词,但我们可以试一试。由于缺乏更好的东西,让我们尝试......

    • 工作站可以“在”办公室。
    • 办公室可能“拥有”一个工作站。

    现在,我们需要提出一些适当的问题,以确定关系的基数。是一对一、一对多、零还是一对多等。我们提出的问题通常是以下形式:

    • 一个办公室可以有多个工作站吗?
    • 一个工作站可以“在”多个办公室吗?
    • 办公室可以有零个工作站吗?
    • 工作站不能“在”办公室吗?

    根据对这些问题的回答,我们确定是否需要建立这种关系...例如,工作站是否必须位于办公室中。这在我们的模型中是强制性的还是可选的?

    (忽略时间数据的建模,对单个时间点的状态进行建模,我们可能会确定:

    • 工作站可以“位于”一或零办公室
    • 办公室可以“拥有”零个、一个或多个工作站

    这是一对多关系的示例,其中关系是可选的。


    我们的一些候选实体将不是我们模型中的实体。例如,也许计算机的“制造商”对业务并不重要,或者我们不需要存储任何信息来存储有关“购买”事件的信息。


    “服务器”和“服务器管理员”的关系...

    • 一个“服务器”可以由多个“服务器管理员”管理吗?
    • “服务器管理员”(人)可以管理多个“服务器”吗?
    • “服务器管理员”(人)可以管理零个服务器吗?
    • “服务器”可以由零个管理员管理吗?

    这很可能在我们的模型中变成多对多关系。 (我们可能会引入一个额外的“administrates”表来解决多对多关系,其中新的“administrates”关系表将与“server”和“server admin”都有外键关系。

    【讨论】:

    • 首先,找出你需要记录的谓词。谓词中的角色将规定实体集。
    猜你喜欢
    • 2014-01-09
    • 2016-04-07
    • 1970-01-01
    • 2017-09-18
    • 1970-01-01
    • 1970-01-01
    • 2013-04-29
    • 1970-01-01
    相关资源
    最近更新 更多