11

我刚开始为我的网站制作数据库，所以我正在重新阅读Database Systems - Design, Implementation and Management (9th Edition)，但我注意到书中没有描述创建一个组织良好和规范化的数据库的一步一步的过程。这本书似乎有点到处都是，尽管规范化过程都在一个地方，但通往它的步骤却不是。

我认为将所有步骤放在一个列表中非常有用，但我在网上或其他任何地方都找不到类似的东西。我意识到解释所有步骤的回答者将是一个相当广泛的步骤，但我能在这个主题上得到的任何东西都将不胜感激；包括规范化前的指令顺序和建议链接。

虽然我对这个过程有点熟悉，但我在设计任何数据库时都休息了很长时间（大约 1 年），所以我希望对所有内容进行详细描述。

我特别感兴趣：

  • 什么是开始建模数据库的好方法（或如何列出业务规则以免混淆）

我想使用 ER 或 EER（扩展实体关系模型），我想知道

  • 如何使用 EER（不相交和重叠）正确建模子类型和超类型（以及写下它的业务规则，以便您知道它是一个子类型，如果有任何常见的方法）

（我已经熟悉规范化过程，但答案也可以包括有关它的提示）

仍然需要帮助：

  • 写下业务规则（包括 EER 中子类型和超类型的业务规则）
  • 如何在 EER 中正确使用子类型和超类型（如何对其建模）

任何其他建议将不胜感激。

4

4 回答 4

2

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

http://www.youtube.com/watch?v=q1GaaGHHAqM

编辑：

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

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

这个想法是进行扩展 ER 建模，因为您不仅可以指定实体，还可以指定 PK 和 FK 以及基数。看看这个链接（查看图形和两种模型之间的区别）。

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

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

看这个Graphic，只创建了 N:M 关系实体（当你看到 2 个或更多 FK 时，这是一个关系表）

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

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

编辑2：

在这里我放了一些可以更好地解释的链接，这将需要很多行并且在这里和我自己更难解释，请查看此链接，如果您有任何问题，请告诉我：

类型和子类型：

业务规则（完整性约束）

于 2012-05-25T18:27:15.027 回答
2

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

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

  1. 创建组织对运营的描述的详细叙述。
  2. 根据操作描述识别业务规则。
  3. 从业务规则中识别主要实体和关系。
  4. 将实体/关系转换为 EER 模型
  5. 检查命名约定
  6. 将 ERR 模型映射到逻辑模型（第 400 页）*
  7. 规范化逻辑模型（第 179 页）
  8. 改进数据库设计（第 187 页）
  9. 验证逻辑模型完整性约束（第 402 页）（如长度等）
  10. 根据用户需求验证逻辑模型
  11. 将表转换为 mySQL 代码（在工作台中，使用导出函数将 EER 转换为 SQL 文件，然后转换为 mySQL）

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


1.详细描述运作公司。如果您正在创建个人项目，请详细描述它如果您正在与公司合作，要求提供描述其公司的文件以及与员工面谈以获取信息（面谈可能会产生不一致的信息，请务必与主管核实哪些信息对设计更重要)
2.查看收集到的信息并开始从中生成规则，确保填补您知识中的任何信息空白。在继续之前与公司的主管确认。
3.从业务规则中识别主要实体和关系。请记住，在设计过程中，数据库设计人员不仅仅依靠访谈来帮助定义实体、属性和关系。通过检查组织在日常运营中使用的业务表格和报告，可以收集到数量惊人的信息。（第 123 页）


4.如果数据库很复杂，您可以将 ERD 设计分解为以下子步骤
i) 创建外部模型 (pg 46)
ii) 组合外部模型以形成概念模型 (pg 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 clustering to further simplify your design process.

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


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

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

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

  1. 映射强实体（不需要其他实体存在的实体）
  2. 映射超类型/子类型关系
  3. 映射弱实体
  4. 映射二元关系
  5. 映射更高程度的关系

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

8.

  1. Refine Attribute Atomicity - 注意原子性要求通常是一种很好的做法。原子属性是不能进一步细分的属性。据说这样的属性显示了原子性。通过提高原子性程度，您还可以获得查询的灵活性。

  2. 根据数据粒度的要求细化主键 - 粒度是指由存储在表行中的值表示的详细程度。如前所述，以最低粒度存储的数据称为原子数据。例如，假设 ASSIGN_HOURS 属性表示给定员工在给定项目上的工作时间。但是，这些值是否记录在它们的最低粒度级别？换句话说，ASSIGN_HOURS 是代表每小时总计、每天总计、每周总计、每月总计还是每年总计？显然，ASSIGN_HOURS 需要更仔细的定义。在这种情况下，相关问题如下：您要在什么时间范围内（小时、日、周、月等）记录 ASSIGN_HOURS 数据？例如，假设 EMP_NUM 和 PROJ_NUM 的组合是 ASSIGNMENT 表中可接受的（复合）主键。该主键仅用于表示员工自项目开始以来在项目上工作的总小时数。使用诸如 ASSIGN_NUM 之类的代理主键可提供更低的粒度并产生更大的灵活性。例如，假设 EMP_NUM 和 PROJ_NUM 组合用作主键，然后员工在 ASSIGNMENT 表中创建了两个“工作小时数”条目。该行为违反了实体完整性要求。即使您将 ASSIGN_DATE 添加为复合 PK 的一部分，如果任何员工在同一天为同一项目输入两个或多个条目，仍会生成实体完整性违规。

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

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

于 2012-06-14T17:01:19.653 回答
0

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

于 2012-07-28T15:36:00.063 回答
0

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

于 2014-12-09T22:24:21.473 回答