我会推荐你这个视频（约 9）关于 E / R 建模

“这个模型的图表必须有多广泛？它们必须包括所有的实体和属性吗？”

是的，实际上你有 ER 建模和扩展 ER 建模，

我们的想法是进行扩展 ER 建模，因为您不仅指定实体，还指定 PK 和 FK 以及基数。看看这个link（请参阅图形和两个模型之间的区别）。

有两种建模方式，一种是真实场景，另一种是 DB 的真实结构，即：

当您创建 E-ER 建模时，您甚至可以为所有实体创建关系和基数，但是当您要创建数据库时，没有必要创建基数为 1：N 的关系（基数为 N 的表创建 FK 卡 1，您不需要在数据库中创建关系表），或者当您具有 1：1 基数时，您知道您的一个实体可以吸收另一个实体。

看这个Graphic，只有 N：M 关系实体被创建（当你看到 2 个或更多的 FK，这是一个关系表）

但请记住，这些只是“规则”，你可以打破它，如果你的设计需要，性能，安全性等。

关于工具，有很多，但我推荐workbench，因为您可以使用它连接到您的 DB（如果您在 mysql 中）并创建设计 E / R 建模，具有属性，他将自动创建关系表 N：M。

在这里，我把一些链接，可以解释一点更好，这将需要很多行，将更难在这里和我自己解释，请查看此链接，让我知道，如果你有问题：

类型和子类型：

业务规则（完整性约束）

http://www.deeptraining.com/litwin/dbdesign/FundamentalsOfRelationalDatabaseDesign.aspx（请特别看看这个，我认为它会帮助你所有这些信息）

我已经重新阅读了这本书和一些在线文章，并创建了一个简短的步骤列表，以便设计一个体面的数据库（当然，您需要先了解数据库设计的基础知识）更详细地描述了步骤：

（书中描述了很多步骤：Database Systems - Design, Implementation and Management (9th Edition)这也是页码所指的，但我将尝试在这里尽可能多地描述，并将在接下来的几天中编辑此答案以使其更完整）

创建组织运营描述的详细叙述。

根据操作描述确定业务规则。

从业务规则中识别主要实体和关系。

将实体 / 关系转换为 EER 模型

检查命名约定

将 ERR 模型映射到逻辑模型 (pg 400) *

规范化逻辑模型 (第 179 页)

改进 DB 设计 (第 187 页)

验证逻辑模型完整性约束 (pg 402) (如长度等)

根据用户要求验证逻辑模型

将表转换为 mySQL 代码（在工作台中使用导出功能将 EER 转换为 SQL 文件，然后转换为 mySQL）

* 如果您使用工作台和您在那里设计的 ER 模型的工作，您可以跳过此步骤。

1.在日常工作中使用关系，而不是在组织中详细描述。如果您正在创建个人项目，请在与公司合作时要求提供描述其公司的文档以及与员工进行面谈以获取信息（面谈可能会产生不一致的信息，请确保与主管检查哪些信息对设计更重要）
2.查看收集的信息并开始从他们中产生规则

4.如果数据库很复杂，您可以将 ERD 设计分解为以下子步骤
i) 创建外部模型 (第 46 页)
ii) 组合外部模型以形成概念模型 (第 48 页)

Follow the following recursive steps for the design (or for each substep) 
    I.   Develop the initial ERD.
    II.  Identify the attributes and primary keys that adequately describe the entities.
    III. Revise and review the ERD.
    IV.  Repeat steps until satisfactory output
You may also use entity cering to further simplify your design process.

通过 ERD 描述数据库：使用实线连接弱实体（弱实体是指没有父实体就无法存在并且在其 PK 中包含父 PK 的实体）。使用虚线连接强实体（强实体是指可以独立于任何其他实体而存在的实体）

5.检查您的名称是否遵循您的命名约定。我曾经在这里提出过命名约定的建议，但人们并不喜欢它们。我建议遵循您自己的标准或在线查找一些命名约定。如果您发现一些非常有用的命名约定，请发表评论。

6.逻辑设计通常涉及将 ER 模型转换为一组关系（表），列和约束定义。

使用以下步骤将 ER 转换为逻辑模型：

映射强实体（不需要其他实体存在的实体）

映射超类型 / 子类型关系

映射弱实体

映射二元关系

映射更高程度的关系

7.规范化逻辑模型。您还可以对逻辑模型进行非规范化，以获得一些所需的特性。（如改进的性能）

细化属性原子性-通常，注意原子性要求是一种很好的做法。原子属性是不能进一步细分的属性。这样的属性被称为显示原子性。通过提高原子性程度，您还可以获得查询灵活性。

Refine Primary Keys as Required for Data Granularity-Granularity 指的是在表的行中存储的值所代表的细节水平较低的情况下，例如 GNEMUN_SIGN_total key 和 SIGN_total_sURUN_total_hours 表示的数据。

尝试回答以下问题：“谁将被允许使用表以及表的哪些部分将可供哪些用户使用？”等等。

请随时在的评论中留下建议或链接到更好的描述，我将把它添加到我的答案中

您的问题的一个方面涉及在 SQL 表中表示子类-超类关系。Martin Fowler 讨论了三种设计方法，其中我最喜欢的是Class Table Inheritance。棘手的部分是安排 Id 字段从超类传播到子类。完成后，您通常要做的连接是光滑，简单和快速的。

设计任何数据库都有六个主骤：1.需求分析 2.概念设计 3.逻辑设计 4.模式细化 5.物理设计 6.应用程序和安全设计。