设计组织良好且规范化的关系数据库的步骤

时间:2012-05-24 04:50:14

标签: mysql sql performance database-design optimization

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

我认为在一个列表中包含所有步骤非常有用,但我无法在网上或其他任何地方找到类似的内容。我意识到回答所有步骤的回答者将是一个非常广泛的步骤,但我将非常感谢任何我可以得到的这个主题;包括规范化前的指令顺序和建议链接。

虽然我对这个过程非常熟悉,但我花了很长时间(约1年)设计任何数据库,所以我想详细描述一切。

我特别感兴趣:

  • 开始建模数据库的好方法(或如何列出业务规则以免混淆)

我想使用ER或EER(扩展实体关系模型),我想知道

  • 如何使用EER(不相交和重叠)正确建模子类型和超类型(以及为其写下业务规则,以便在有任何常用方法时知道它是一个子类型)

(我已经熟悉了规范化过程,但答案也可能包含有关它的提示)

仍然需要帮助:

  • 写下业务规则(包括EER中的子类型和超类型的业务规则)
  • 如何正确使用EER中的子类型和超类型(如何建模)

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

4 个答案:

答案 0 :(得分:2)

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

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

修改

“这个模型的图表必须有多大?它们必须包含所有实体和属性吗?”

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

我们的想法是进行扩展ER建模,因为您不仅可以指定实体,还可以指定PK和FK以及基数。看看这个link(参见图形和两个模型之间的差异)。

有两种建模方式,一种是真实场景,另一种是DB的真实结构,I.E:

当您创建E-ER建模时,您甚至可以为所有实体创建关系和基数,但是当您要创建数据库时,不必创建与基数1:N的关系(具有基数N的表创建一个FK来自带卡的表.1,您不需要在DB中创建关系表,或者当您拥有1:1的基数时,您知道您的某个实体可以吸收另一个实体。

看这个Graphic,只创建N:M关系实体(当你看到2个或更多FK时,那是一个关系表)

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

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

编辑2:

这里我提供了一些可以解释得更好一些的链接,这将需要很多细节,并且在这里和我自己更难解释,请查看此链接并告诉我您是否有疑问:

类型和子类型:

业务规则(完整性约束)

答案 1 :(得分:2)

我已经在线阅读了本书和一些文章,并创建了一个简短的步骤列表,以便设计一个像样的数据库(当然,您需要首先了解数据库设计的基础知识)步骤将在下面详细介绍:< / p>

(书中描述了很多步骤: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)
  12. *如果您使用工作台和您在那里设计的ER模型的工作,您可以跳过此步骤。


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


    4。
    如果数据库很复杂,您可以将ERD设计分解为followig子步骤     
    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 clustering to further simplify your design process.
    

    通过ERD描述数据库: 使用实线连接弱实体(弱实体是那些在没有父实体的情况下不存在且在PK中包含父PK的实体)。 使用虚线连接强实体(强实体是可以独立于任何其他实体存在的实体)


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

    <强> 6 逻辑设计通常涉及将ER模型转换为一组关系(表),列和约束定义。

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

    1. 映射强实体(不需要其他实体存在的实体)
    2. 映射超类型/子类型关系
    3. 映射弱实体
    4. 映射二进制关系
    5. 映射更高程度的关系
    6. 7. 规范化逻辑模型。您还可以对逻辑模型进行非规范化以获得某些所需的特征。 (如改善表现)

      8。

      1. 优化属性原子性 - 一般来说,注意原子性要求是一种好习惯。原子属性是不能的属性 进一步细分。据说这种属性显示原子性。通过提高原子性程度,您还可以获得查询灵活性。

      2. 根据数据粒度要求优化主键 - 粒度是指存储在表格行中的值所表示的详细程度。数据存储在最低位置 如前所述,粒度级别被称为原子数据。例如,假设ASSIGN_HOURS属性表示给定员工在给定项目上工作的小时数。但是,是 这些值是以最低粒度记录的?换句话说,ASSIGN_HOURS代表每小时 总计,每日总计,每周总计,每月总计或每年总计?显然,ASSIGN_HOURS需要更仔细的定义。在这种情况下,相关的问题如下:在什么时间框架 - 小时,日,周,月和 那么你想记录ASSIGN_HOURS数据吗? 例如,假设EMP_NUM和PROJ_NUM的组合是可接受的(复合)主键 在ASSIGNMENT表中。该主键仅用于表示员工的总小时数 从一开始就参与了一个项目。使用代理主键(例如ASSIGN_NUM)可提供更低的粒度 并产生更大的灵活性。例如,假设使用EMP_NUM和PROJ_NUM组合作为 主键,然后员工在ASSIGNMENT表中生成两个“小时工作”条目。这个行为违反了 实体完整性要求。即使您将ASSIGN_DATE添加为复合PK的一部分,也是实体完整性 如果任何员工在同一天为同一项目输入两个或更多条目,则仍会生成违规。 (该 员工可能在早上几个小时就开始工作,然后在当天晚些时候再次工作。) 当ASSIGN_NUM用作主键时,相同的数据输入不会产生任何问题。

      3. 尝试回答以下问题:&#34;谁将被允许使用这些表格,哪些用户可以使用哪些表格?&#34; ETC。

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

答案 2 :(得分:0)

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

答案 3 :(得分:0)

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