Clever Geek Handbook

数据库设计规则的基础

介绍



通常，数据库架构师需要为特定解决方案开发数据库。

一个星期五晚上，在下班回家的火车上，我想到了我将如何创建一种服务来雇用不同公司的员工。毕竟，任何现有服务都无法让您快速了解候选人对您的适合程度。无法创建包含或排除一组特定技能，项目或职位的复杂过滤器。通常，服务最多提供的是按公司过滤的过滤器，部分是按技能过滤的过滤器。



在本文中，我将通过将技术信息与生活中的非技术示例相混合，来稍微削弱材料的严格呈现。



首先，让我们分析一下MS SQL Server中用于职位搜索服务的数据库的创建。



可以将这些资料转移到另一个DBMS，例如MySQL或PostgreSQL。



设计规则的基础



设计数据库模式时，您需要记住7条形式规则以及规范化和非规范化的概念。它们是所有设计规则的基础。



让我们更详细地描述7个正式规则：



  1. 一对一关系：



    1.1）具有强制联系：



    一个例子可以是公民及其护照：任何公民必须拥有护照；每个公民一张护照



    这种关系可以通过两种方式实现：



    1.1.1）在一个实体（表）中：图1。公民实体 这里的公民表是公民实体，PassportData属性（字段）包含公民的所有护照数据，并且不能为空（NOT NULL）。 2）在两个不同的实体（表）中：图2。公民和PassportData实体之间的关系























    这里的公民表是公民实体，而护照数据表是公民的护照数据实体（护照本身）。公民实体包含一个PassportID属性（字段），该属性引用PassportData表的主键。护照数据实体又包含属性（字段）CitizenID，该属性引用Citizen表的主键CitizenID。市民表PassportID字段不能为空（NOT NULL）。保持PassportData表的CitizenID字段的完整性以确保一对一关系也很重要。换句话说，Citizen表的PassportID字段和PassportData表的CitizenID字段必须引用相同的记录，就好像它是第1.1.1节中介绍的相同实体（表）一样。



    1.2）和一个可选链接：



    一个例子是有或没有护照的特定国家的人。在第一种情况下，他将是所涉国家的公民，在第二种情况下，他将不会。



    这种关系可以通过两种方式实现：



    1.2.1）在一个实体（表）中：图3。 Person实体Person 表是一个人的实体，PassportData属性（字段）包含其所有护照数据，并且可以为空（NULL）。 2）在两个实体（表）中：图4。人员和PassportData实体之间的关系























    Person表是该人的实体，PassportData表是该人的护照数据实体（护照本身）。人工实体包含一个PassportID属性（字段），该属性引用PassportData表的主键。护照数据的身份又包含属性（字段）PersonID，它是指Person表的主键PersonID。人员表的PassportID字段可以为NULL。保持PassportData表的PersonID字段的完整性也很重要。这是确保一对一通信所必需的。 Person表的PassportID字段和PassportData表的PersonID字段必须引用相同的记录，就好像它是第1.2.1节中所示的相同实体（表）一样。或者，这些字段必须为null，即包含NULL。

  2. :



    2.1) :



    . .



    :



    2.1.1) ():





    .5. Parent



    Parent , () ChildList . (NOT NULL). ChildList (NoSQL) XML, JSON .



    2.1.2) ():





    .6. Parent Child



    Parent , Child — . Child ParentID, ParentID Parent. ParentID Child (NOT NULL).



    2.2) :



    , .



    :



    2.2.1) ():





    .7. Person



    Parent , () ChildList . (NULL). ChildList (NoSQL) XML, JSON .



    2.2.2) ():





    .8. Person Child



    Parent , Child — . Child ParentID, ParentID Parent. ParentID Child (NULL).



    2.2.3) , () () :





    .9. Person



    () Person () ParentID, PersonID Person (NULL).



    « » .

  3. :



    . , «» «», , . , , .

  4. :



    : , . , .



    , NoSQL, , . , 3 ():





    .10. Person RealEstate



    Person RealEstate . () () PersonRealEstate. () PersonID RealEstateID PersonID Person RealEstateID RealEstate . , PersonRealEstate (PersonID; RealEstateID) PersonRealEstate.



    . , . , 1.1.2 1.2.2.



一对多和多对一 关系可以通过两个以上的实体来实现。为此，添加了必要的属性，这些属性引用了必要的相应实体的主键。此实现类似于上面第1.1.2和1.2.2段中描述的示例。



七个正式规则在哪里？



他们来了：



  1. 第1条（第1.1条和第1.2条）-第一和第二条正式规则
  2. 第2条（第2.1条和第2.2条）-第三和第四条正式规则
  3. 第3条（类似于第2条）-第五和第六条正式规则
  4. 项目4-第七条正式规则


在上面的文本中，这七个正式规则分为四个功能块。



在谈论规范化时，您需要了解其本质。归一化导致信息存储的可重复性降低，因此导致数据异常的可能性降低。但是，拆分实体时的规范化导致用于数据操作（插入，修改，选择和删除）的查询结构更加复杂。



反向规范化过程称为反规范化。由于实体的聚合和嵌套（例如，如上文第2.1.1和2.2.1段中所示，使用不完全结构化的数据（NoSQL）），这简化了构建数据访问查询的过程。



这就是数据库设计规则的重点。



您确定您了解七个正式规则中的关系吗？您了解但不认识吗？毕竟，了解和理解是两个完全不同的概念。



我将更详细地解释。问问自己，您是否可以在几个小时内为任何主题领域和任何信息系统勾勒出一个数据库模型，尽管它被实体放大了？ （细节和细节可以通过询问分析师和客户代表来完成）。如果问题使您感到惊讶，并且您认为这是不可能的，那么您知道这七个正式规则，但不了解它们。



由于某些原因，许多消息来源忽略了这些关系不是被发明而是被揭示的事实。它们最初存在于现实世界中，既在主体之间，又在主体和客体之间。



而且，这种关系可以改变，从一对一到一对多，多对一或多对多的。交流的义务可以改变或保持不变。



让我告诉你一个案例，当我从七个正式规则的知识中得出我对这些关系的理解时。



一次让我感到尴尬的是，在大学里我知道这七个正式规则，但是在很长一段时间的工业实践中（大学将学生送到各种公司以获取专业经验），我为不同学科领域建立了基础模型。我考虑了一下，意识到我不了解这种关系。



观察人们对我有帮助，这种关系的本质在梦中被揭示。我将以简化的形式复述这个梦想：只有能让您更好地理解这七个正式规则的东西-而无需详述其他所有内容。



梦想是关于一个有父亲，母亲和孩子的家庭。父亲死于车祸，母亲开始喝酒，孩子们最终被带到孤儿院。这些孩子长时间没有父母陪伴。然后有些孩子有监护人，也有几个。



您是否跟踪了主题之间的什么样的关系，以及这些关系如何变化？

让我们仔细看看。



  • 当一个有几个孩子的家庭建成后，父母与孩子之间的关系是多对多的。
  • , . , , , , .
  • .
  • — .
  • , : , ().


夫妻间的关系是一对一用一强制性键在正式婚姻，或一到一个具有可选键之前注册。只能有一个妻子，就像只能有一个丈夫一样。至少在俄罗斯。但是在另一个国家，一夫多妻制是可能的，那么丈夫和妻子之间的关系将是一对多的，妻子和丈夫之间的关系将是一对多的。



希望您现在更加了解这七个正式规则。



值得不断练习：观察人们并确定主题之间以及主题和对象之间的现有关系。上面将公民及其护照描述为一对一关系，带有强制链接...同时，一个人及其护照的例子是带有可选链接的一对一关系。



了解了七个正式规则后，您可以轻松地为任何信息系统设计任何复杂性的数据库模型。



您还将看到实现关系的方法有很多，并且关系本身可以更改。数据库模型（模式）是实体在特定时间点之间的关系的快照。因此，考虑到未来的变化，确定实体本身（来自现实世界或主题区域的物体的图像以及它们之间的关系）非常重要。



一个经过精心设计的数据库模型，考虑到现实中或领域中不断变化的关系，多年甚至数十年都不需要更改。这对于数据仓库尤为重要，因为在数据仓库中，更改涉及重新存储大量数据（从几GB到几TB）。



重要的是要记住，关系模型中的表是实体关系，而行（元组）是这些关系的实例。但是为了简化起见，表通常被理解为实体，而表行是实体实例。它们的关系通过外键形式的关系表示。



设计数据库架构以查找求职者



在第一部分介绍了数据库设计规则的基础之后，让我们创建一个数据库架构以查找求职者。



首先，让我们定义对于公司中正在寻找候选人的员工来说重要的是：



  1. 对于人力资源：



    1.1）申请人工作的公司

    1.2）申请人先前在这些公司中担任的职位

    1.3）申请人在工作中使用的技能和能力；

    以及申请人在每个公司在每个职位上的工作时间以及使用每种技能和能力的时间

  2. 对于技术专家：



    2.1）申请人在这些公司中的职位；

    2.2）申请人在工作中使用的技能和能力；

    2.3）申请人参与的项目；

    以及申请人在每个职位和每个项目中的工作时间，每种技能和能力的使用时间



首先，让我们确定所需的实体：



  1. 雇员
  2. 公司
  3. 位置（position）
  4. 项目
  5. 技能


  • 公司和员工就像许多人一样，因为一个员工可以在几家公司工作，并且很多人在公司工作。
  • 职位和员工之间的关系类似：几个员工可以在一个或多个公司中担任一个职位。
  • , , . , — .
  • : .
  • , .
  • .


由于记录员工在特定公司的特定职位以及每个项目中工作了多长时间非常重要，因此我们的数据库图可能如下所示：图11。查找求职者的数据库架构 这里，JobHistory表充当每个求职者的工作历史的实体。也就是说，它是一份简历，介绍了实体员工，公司，职位和项目之间的多对多关系。 项目和技能之间的关系是多对多的，因此可以通过ProjectSkill实体（表）相互交流。

















当您了解主体之间以及主体与客体之间的关系时（已经提到的七个正式规则），可以在不到一个小时的时间内“在膝盖上”实施这种或类似的方案。而且，这还考虑到一天工作成果丰硕之后的疲劳感。



如果将“技能”通过XML，JSON形式的不完整结构化数据（NoSQL）嵌入“项目”实体中，或者仅列出用分号分隔的技能名称，则可以简化数据添加方案。但这将使按技能采样和按技能过滤变得更加困难。



类似的模型是Geecko项目数据库的核心。



如您所见，就数据库设计而言，信息系统的设计并不复杂。这只是现实中的对象和主题的反映，已转移到数据库架构的“实体”。考虑到未来的变化，这些实体之间的关系固定在某个时间点。



我们究竟要从现实中真正获取什么并将其纳入方案的本质，以及我们在模型中建立的关系，将取决于我们在当前和将来对信息系统的总体需求。换句话说，我们希望在当前时间和将来的某个时间之后接收什么数据。



一点歌词



将模型投入使用后，停下来思考一下：刚刚创建了一个新的小世界。它具有来自现实世界的自己的实体和自己的关系。是的，这是一个数字世界，但是现在它将以自己的方式发展。他将与也根据自己的规则创建的其他系统（世界）进行通信（集成）。数据将像活体中的血液一样在这些系统中流动。



在上床睡觉之前，请考虑以下事实：这七个正式规则一直存在，并且遍布我们各处。不多也不少，总是七个。现实生活中的所有关系都可以分解为这七个正式规则。而当您思考或做梦时，实体之间是如何相互关联的-不是按照相同的七个正式规则？



总的来说，我确信这种关系（七个正式规则）是由非常好的心理治疗师（可能是女性）揭示出来的。很久以前，很早就出现了信息技术的概念。最有趣的是，这些关系存在于数据库和IT之外-后者仅使用它们为信息系统建模。



但是我们偏离了这个话题。我只在此刻敦促创建一个新的系统，以诚恳的态度对待这一过程。然后相信我，创造的时刻将会发生。以这种方式设计的系统将是数字世界中所有生命中最活泼的。



后记



使用SQL Server数据库图工具实现了示例图。但是，DBeaver具有类似的功能。



资料来源





More articles:


All Articles