文章目录

一、引言
二、学习
- 1. 实体-联系模型
- - 1.1. 实体集
  - 1.2. 联系集
  - 1.3. 属性
- 2. 约束
- - 2.1. 映射基数
  - 2.2. 参与约束
  - 2.3. 码
  - 2.4. 从实体集中删除冗余属性
- 3. 总结

一、引言

最近在学习使用.NET中的EF Core来访问数据库。从一开始的SQL语句直接访问到后来的EF Core（O/RM）访问，再到EF Core用了一段时间后，发现数据表及关系设计很关键。

其实只是访问数据库很简单，问题是随着理解变深，数据变复杂，数据表还有表间的关系到底该怎么设计，怎么设计才能访问的更舒服，还有表与表之间联系的本质到底是什么。本以为学了EF Core，会简单使用就好了，结果发现用的过程中问题越来越多，疑惑越来越大。

所以只能继续对概念进行深入学习理解。
正好前段时间看到 《数据库系统概念》 这本书，也学了其中一个章节——关系模型，感觉理解加深了，而该书第七章——实体-联系模型，其中又有不少我听闻过，但理解不深的概念，于是我决定写篇blog来学习一下。

二、学习

1. 实体-联系模型

实体-联系（entity-relationship，简称E-R模型）数据模型的提出旨在方便数据库的设计（平时说的实体关系模型应该也是指它），它是通过允许定义代表数据库全局逻辑结构的企业模式实现的。
E-R模型在将现实世界企业的含义和交互映射到概念模式上非常有用，因此，许多数据库设计工具都利用了E-R模型的概念。E-R数据模型采用了三个基本概念：实体集、联系集和属性。

这边突然冒出企业模式这个词，那E-R数据模型和企业有什么关系？
这边可以理解为E-R数据模型是基于企业应用的。用于企业级别的数据库设计。

1.1. 实体集

实体（entity）是现实世界中可区别于所有其他对象的一个“事物”或“对象”。例如，大学中的每个人都是一个实体。每个实体都有一组性质，其中一些性质的值可以唯一地标识一个实体。例如，一个人可能具有person_id性质唯一标识这个人。与此类似，课程也可以看作实体，而course_id唯一标识了大学中某个课程实体。实体可以是实实在在的，如人或书；也可以是抽象的，如课程、课程段开课或机票预订。

所以可以将实体理解为现实世界中的一类物体（实际的或抽象的）。
事实上，数据表设计时，表中往往会设一个id来唯一标识实体

实体集（entity set）是相同类型即具有相同性质（或属性）的一个实体集合（回过头去看EF Core中上下文是通过DbSet<T>来暴露实体的，是不是某种程度上也可以理解为是实体集）。一所给定大学的所有教师的集合可定义为实体集instructor。类似地，实体集student可以表示大学中所有学生的集合。

在建模的过程中，我们通常抽象地使用术语实体集，而不是指某个个别实体的特别集合。我们用术语实体集的外延（extension）来指属于实体集的实体的实际集合。因此，大学中实际教师的集合构成了实体集instructor的外延。与第二章中提到的关系与关系实例之间的区别类似。（关系就是这类表，关系实例就是某张具体的表）

实体集不必互不相交。例如，可以定义大学里所有人的实体集（person）。一个person实体可以是instructor实体，可以是student实体，可以既是instructor实体又是student实体，也可以都不是。

实体通过一组属性（attribute）来表示。属性是实体集中每个成员所拥有的描述性性质。为某实体集指定一个属性表明数据库为该实体集中每个实体存储相似的信息；但每个实体在每个属性上都有各自的值。实体集instructor可能具有属性ID、name、dept_name和salary。在现实生活中，可能还有更多的属性，如街道号、房间号、州、邮政编码和国家，但是为了使我们的例子简单，我们省略了这些属性。course实体集可能的属性有course_id、title、dept_name和credits。

每个实体的每个属性都有一个值（value）。例如，一个特定的instructor实体可能的ID值为12121，name的值为吴，dept_name的值为金融，salary的值为90000。

ID属性用来唯一地标识教师，因为可能会有多个教师拥有相同的名字。在美国，许多企业发现将一个人的社会保障号用作其值唯一标识该人的属性很方便。一般来说，大学必须给每个教师创建和分配一个唯一的标识符。

因此，数据库包括一组实体集，每个实体集包括任意数量的相同类型的实体。

实体集看起来有点类似关系数据模型中的关系的概念（数据表）。

1.2. 联系集

联系（relationship）是指多个实体间的相互关联。例如，我们可以定义关联教师Katz和学生Shankar的联系advisor（指导）。这一联系指明Katz是学生Shankar的导师。

联系集（relationship set）是相同类型联系的集合。正规地说，联系集是n≥2个（可能相同的）实体集上的数学关系。如果E₁，E₂，…，E_n为实体集，那么联系集R是
{(e₁, e₂, …, e_n) | e₁∈E₁, e₂∈E₂, …, e_n∈E_n}
的一个子集，而(e₁, e₂, …, e_n)是一个联系。

各实体集中取一个（或零个）实体，如果它们是相关的，那就构成一个联系。用(e₁，e₂，…，e_n)表示该联系。

考虑以下两个实体集instructor和student。

我们定义联系集advisor来表示教师和学生之间的关联。这一关联如下图所示：

再看另一个例子，考虑实体集student和section。我们可以定义联系集takes来表示学生和该学生所注册的开课之间的关联。

实体集之间的关联称为参与；也就是说，实体集E₁，E₂，…，E_n参与（participate）联系集R。E-R模式中的一个联系实例（relationship instance）表示在所建模的现实世界企业中命名实体间的一个关联。例如，一个教室ID为45565的instructor实体katz和一个学生ID为12345的student实体Shankar参与到advisor的一个联系实例中。这一联系实例表示在大学中教师Katz指导学生Shankar。

实体在联系中扮演的功能称为实体的角色（role）。由于参与一个联系集的实体集通常是互异的，因此角色是隐含的并且一般不指定。

实际应用时，通常是两个不同的实体集之间有关系，一般不会是自己和自己有关系。

但是，当联系的含义需要解释时角色是很有用的。当参与联系集的实体集并非互异时就是这种情况；也就是说，同样的实体集以不同的角色参与一个联系集多于一次。在这类联系集中，即有时称作自环的（recursive）联系集中，有必要用显式的角色名来指明实体是如何参与联系实例的。例如，考虑记录大学开设的所有课程的信息的实体集course。我们用course实体的有序对来建模联系集prereq（prerequisite，预备课程），以描述一门课程（C2）是另一门课程（C1）的先修课。每对课程中的第一门课程具有课程C1的角色，而第二门课程具有先修课C2的角色。按照这种方式，所有的prereq联系通过（C1， C2）对来表示，排除了（C2，C1）对。

联系也可以具有描述性属性（descriptive attribute）。考虑实体集instructor和student之间的联系集advisor。注意，katz在两个不同的日期成为了两名学生的导师。

作为联系的描述性属性的一个更实际的例子，考虑实体集student和section参与一个联系集takes。我们也许希望在这个联系中用一个描述性属性grade，来记录学生在这门课中取得的成绩。我们同样可以用一个描述性的属性for_credit来记录学生在这门课中是选修还是旁听（或出席）的情况。

给定的联系集中的一个联系实例必须是由其参与实体唯一标识的，而不必使用描述属性。为了理解这一点，假设我们要对一个教师成为一个特定学生的导师的所有日期建模。单值的属性date只能保存一个日期。我们不能通过同一个教师和学生之间的多个联系实例来表示多个日期，因为这些联系实例仅使用参与的实体是无法唯一标识的。正确的处理方法是创建一个多值属性date，它可以保存所有的日期。

相同的实体集可能会参与到多于一个联系集中。在我们的例子中，instructor和student实体集参与到联系集advisor中。另外，假设每个学生必须有一名教师作为他的系导师（本科或研究生），那么instructor和student实体集将参与到另一个联系集dept_advisor中。

联系集advisor和dept_advisor给出了二元（binary）联系集的例子，即涉及两个实体集的联系集。数据库系统中大部分联系集都是二元的。然而，有时联系集会涉及多于两个实体集。

例如，假设我们有一个代表在大学内开展的所有研究项目的实体集project，考虑实体集instructor、student和project。每个项目可以有多个参与的学生和多个参与的老师。另外，每个参与项目的学生必须有一个教师指导他在项目中的工作。目前，我们忽略项目和教师以及项目和学生这两个关联，而关注哪个教师在一个特定项目上指导哪个学生。为了表达这个信息，我们通过关联proj_guide将三个实体集联系到一起，它表示某个学生在某个项目上接收了某个导师的指导。

注意，一个学生可以在不同的项目中有不同的教师作为导师，不能将这个联系描述成学生和教师之间的二元关系。

参与联系集的实体集的数目称为联系集的度（degree）。二元联系集的度为2；三元联系集的度为3。

度的概念在数据结构中也有，树的度，图的度。在树中就是节点的孩子树。无向图的度就是与顶点相关联的边的数量。联系的度有点类似无向图的度，可以看成联系（这条线）所连接的实体集的个数。

1.3. 属性

每个属性都有一个可取值的集合，称为该属性的域（domain），或者值集（value set）。course_id属性的域可能是特定长度的所有文本字符串的集合（也可知id往往是文本字符串）。类似地，属性semester（学期）的域可能是集合{秋，冬，春，夏}中的字符串。

正规地说，实体集的属性是将实体集映射到域的函数。
确实，由一组属性的具体的值（a1，a2，a3）可以确定一个实体，
不就是相当于将这一组属性值经一定规则映射到了某个实体上么？这不就是函数。
由于一个实体集可能有多个属性，因此每个实体可以用一组（属性，数据值）对来表示，实体集的每个属性对应一个这样的对。例如，某个instructor实体可以由集合{(ID, 76766), (name, Crick), (dept_name, 生物), (salary, 72000)}来描述，该实体描述了一个叫Crick的人，他的教师编号为76766，是生物系的成员，工资为$72000。从这里我们可以看出抽象模式与被建模的实际企业的结合。用来描述实体的属性值构成存储在数据库中的数据的一个重要部分。

E-R模型中的属性可以按照如下的属性类型来进行划分：

简单（simple）和复合（composite）属性。在我们的例子中，迄今为止出现的属性都是简单属性，也就是说，它们不能划分为更小的部分（简单属性可以认为是原子的？值类型）。另一方面，复合（composite）属性可以再划分为更小的部分（即其他属性）。例如，属性name可设计为一个包括first_name、middle_initial和last_name的复合属性。如果一个用户希望在一些场景中引用完整的属性，而在另外的场景中仅引用属性的一部分，则在设计模式中使用复合属性是一个很好的选择。假设我们要给student实体集增加一个地址。地址可定义为包含属性street、city、state和zip_code的复合属性address。复合属性帮助我们把相关属性聚集起来，使模型更清晰。

注意，复合属性可以是有层次的。在复合属性address中，其子属性street可以进一步分为street_number、street_name和apartment_number。下图描述了instructor实体集的这些复合属性的例子。

单值（single-valued）和多值（multivalued）属性。我们的例子中的属性对一个特定实体都只有单独的一个值。例如，对某个特定的学生实体而言，student_ID属性只对应于一个学生ID。这样的属性称作是单值的（single valued）。而在某些情况下对某个特定实体而言，一个属性可能对应于一组值。假设我们往instructor实体集添加一个phone_number属性，每个教师可以有零个、一个或多个电话号码，不同的教师可以有不同数量的电话。这样的属性称作是多值（multivalued）的。另一个例子，我们可以往实体集instructor中添加一个属性dependent_name，它列出所有的眷属。这个属性将是多值的，因为任何一个特定的教师可能有零个、一个或多个眷属。

为了表示一个属性是多值的，我们用花括号将属性名括住，例如：{phone_number}或{dependent_name}。

在适当的情况下，可以对一个多值属性的取值数目设置上、下界。例如，一所大学可能将单个教师的电话号码个数限制在两个以内。在这个例子中设置限制表明instructor实体集的phone_number属性可以有0~2个值。

派生（derived）属性。这类属性的值可以从别的相关属性或实体派生出来。例如，假设instructor实体集有一个属性students_advised，表示一个教师指导了多少个学生。我们可以通过统计与一个教师相关联的所有student实体的数目来得到这个属性的值。
又如，假设instructor实体集具有属性age，表示教师的年龄。如果instructor实体集还具有属性date_of_birth，我们就可以从当前的日期和date_of_birth计算出age。因此age就是派生属性。在这里，date_of_birth可以称为基属性，或存储的属性。派生属性的值并不存储，而是在需要时计算出来。

当实体在某个属性上没有值时使用空（null）值。空值可以表示“不适用”，即该实体的这个属性不存在值。例如，一个人可能没有中间名字。空还可以原来表示属性值未知。未知的值可能是缺失的（值存在，但我们没有该信息），或不知道的（我们并不知道该值是否确实存在）。

例如，如果一个特定的教师的name指是空，我们推测这个值是缺失的，因为每个教师肯定有一个名字。apartment_number属性的空值可能意味着地址不包括房间号（不适用），或房间号缺失，或我们不知道房间号是否是该教师的地址的一部分（未知的值）。

2. 约束

E-R企业模式可以定义一些数据库中的数据必须要满足的约束。

2.1. 映射基数

映射基数（mapping cardinality），或基数比率，表示一个实体通过一个联系集能关联的实体的个数。

映射基数在描述二元联系集时非常有用，尽管它们可以用于描述涉及多于两个实体集的联系集。在这一节中，我们将只集中在二元联系集上。

对于实体集A和B之间的二元联系集R来说，映射基数必然是以下情况之一：

一对一（one-to-one）。A中的一个实体至多与B中的一个实体相关联，并且B中的一个实体也至多与A中的一个实体相关联。
一对多（one-to-many）。A中的一个实体可以与B中的任意数目（零个或多个）实体相关联，而B中的一个实体至多与A中的一个实体相关联。
多对一（many-to-one）。A中的一个实体至多与B中的一个实体相关联，而B中的一个实体可以与A中任意数目（零个或多个）实体相关联。
多对多（many-to-many）。A中的一个实体可以与B中的任意数目（零个或多个）实体相关联，而且B中的一个实体也可以与A中任意数目（零个或多个）实体相关联。

显然，一个特定联系集的适当的映射基数依赖于该联系集所建模的现实世界的情况。
作为例子，考虑advisor联系集。如果在一所特定的大学中，一名学生只能由一名教师指导，而一名教师可以指导多个学生，那么instructor到student的联系集是一对多的。如果一名学生可以由多名教师指导（比如学生可以由多名教师共同指导），那么此联系集是多对多的。

2.2. 参与约束

如果实体集E中的每个实体都参与到联系集R的至少一个联系中，实体集E在联系集R中的参与称为全部（total）的。如果E中只有部分实体参与到R的联系中，实体集E到联系集R的参与称为部分（partial）的。如上图的a中，B在联系集中的参与是全部的，而A在联系几回中的参与是部分的；在上图的b总，A和B在联系集中的参与都是全部的。

例如，我们期望每个student实体通过advisor联系同至少一名教师相联系，因而student在联系集advisor中的参与是全部的。相反地，一个instructor不是必须要指导一个学生。因此，很可能只有一部分instructor实体通过advisor联系同student实体集相关联，于是instructor在advisor联系集中的参与是部分的。

2.3. 码

我们必须有一个区分给定实体集中的实体的方法。从概念上来说，各个实体是互异的；但从数据库的观点来看，它们的区别必须通过其属性来表明。

现实世界个体间具有差异性，在数据库中是用属性来区分。

因此，一个实体的属性的值必须可以唯一标识该实体。也就是说，在一个实体集中不允许两个实体对于所有属性都具有完全相同的值。

在关系模式中的码的概念直接适用于实体集。即实体的码是一个足以区分每个实体的属性集。关系模式中的超码、候选码、主码的概念同样适用于实体集。

码同样用于唯一地标识联系，并从而将联系互相区分开来。
实体集的主码使得我们可以区分实体集中不同的实体。我们需要一种类似的机制来区分联系集中不同的联系。

设R是一个涉及实体集E₁，E₂，…，E_n的联系集。设主码（E_i）代表构成实体集E_i的主码的属性集合。目前我们假设所有主码的属性名是互不相同的。联系集主码的构成依赖于同联系集R相关联的属性集合。
如下图，椭圆E₁、E₂、…、E_n代表不同实体集，椭圆中的（p1，p2，…，pn）代表该实体的属性集，带下划线的表示主码。它们之间的所有连线表示联系集R。

如果联系集R没有属性与之相关联，那么属性集合
primary-key(E₁)∪primary-key(E₂)∪…∪primary-key(E_n)
描述了集合R中的一个联系。

该情况下，相当于我确定了主码后，就等于确定了各实体集中的唯一实体。实体确定后，实体间的联系也就确定了。

如果联系集R有属性a₁，a₂，…，a_m与之相关联，那么属性集合
primary-key(E₁)∪primary-key(E₂)∪…∪primary-key(E_n)∪{a₁，a₂，…，a_m}
描述了集合R中的一个联系。
在以上两种情况下，属性集合
primary-key(E₁)∪primary-key(E₂)∪…∪primary-key(E_n)
构成了联系集的一个超码。

如果实体集间主码的属性名称不是互不相同的，重命名这些属性以区分它们；实体集的名字上加上属性名可以构成唯一的名称。如果一个实体集不止一次参与某个联系集（如前面提到的prereq联系，前置课程），则使用角色名代替实体集名构成唯一的属性名。

联系集的主码结构依赖于联系集的映射基数。例如，实体集instructor和student以及具有属性date的联系集advisor。假设联系是多对多的，那么advisor的主码由instructor和student的主码并集组成。如果联系是从student到instructor多对一的，即每个学生最多只能有一个导师，则student的主码就是advisor的主码。而如果一名教师只能指导一名学生，则联系是从instructor到student多对一的，则instructor的主码就是advisor的主码。对于一对一的联系，两个候选码中的任意一个可以用作主码。

对于非二元联系，如果没有基数的限制，那么本节开始时描述的超码就是唯一的候选码。并被选为主码。如果有基数的限制，主码的选择就复杂多了。如何在非二元关系中描述基数约束，在后面章节会详细考虑。

2.4. 从实体集中删除冗余属性

当我们使用E-R模型设计数据库时，我们通常从确定那些应当包含的实体集开始。例如，在我们迄今所讨论的大学机构中，我们想要包含如student和instructor等实体集。当决定好实体集后，我们必须挑选适当的属性，这些属性要表示我们在数据库中所捕获的不同的值。在大学机构中，我们为instructor实体集设计了包括ID、name、dept_name以及salary几个属性，我们还可以添加phone_number、office_number、home_page等属性。要包含哪些属性的选择决定于了解企业结构的设计者。

从零开始设计一个企业级数据库需要很多步骤的。

确定包含的实体集

为实体集选择属性

这两步完成后，实体部分差不多完成了，接下来开始联系部分。

一旦选择好实体和它们相应的属性，不同实体间的联系集就建立起来了。这些联系集有可能会导致不同实体集中的属性冗余，并需要将其从原始实体集中删除。为了说明这一点，考虑实体集instructor和department：

实体集instructor包含属性ID、name、dept_name以及salary，其中ID构成主码。
实体集department包含属性dept_name、building以及budget，其中dept_name构成主码。

我们用关联instructor和department的联系集inst_dept对每个教师都有一个关联的系的情况建模。

属性dept_name在两个实体集中都出现了。由于它是实体集department的主码，因此它在实体集instructor中是冗余的，需要将其移除。

从实体集instructor中移除属性dept_name可能不是那么直观，因为我们在前几章所用到的关系instructor中具有dept_name属性。我们将在后面看到，当我们从E-R图构建一个关系模型时，只有当每个教师最多只与一个系关联时，属性dept_name才会添加到关系instructor中。

将教师和系之间的关联统一看成联系，而不是instructor的一个属性，使得逻辑关系明确，并有助于避免过早地假设每个教师只与一个系关联。

类似地，实体集student通过联系集student_dept与实体集department关联，因而student中不需要dept_name属性。

另一个例子，考虑开课（section）和开课的时段。每个时段都由time_slot_id标识，并且和上课时间的集合相关联，每次上课时间都由星期几、开始时间以及结束时间标识。我们打算使用多值复合属性对应上课时间集合建模。假设我们对实体集section和time_slot按以下方式建模：

实体集section包含属性course_id、sec_id、semester、year、building、room_number以及time_slot_id，其中（course_id，sec_id，year，semester）构成主码。
实体集time_slot包含主码属性time_slot_id，以及一个多值复合属性{(day，start_time，end_time)}。

这些实体通过联系集sec_time_slot相互关联。
属性time_slot_id在两个实体集中均出现。由于它是实体集time_slot的主码，因此它在实体集section中是冗余的，并且需要将其删除。

最后一个例子，假设我们有一个实体集classroom，包含属性building、room_number以及capacity，主码由building和room_number组成。再假设我们有一个联系集sec_class，将section和classroom关联在一起。那么属性{building，room_number}在实体集中是冗余的。

一个好的实体-联系设计不包含冗余的属性。对于我们大学的例子，我们在下面列出实体集以及它们的属性，主码以下划线标明。

classroom：包含属性（building、room_number、capacity）。
department：包含属性（dept_name、building、budget）。
course：包含属性（course_id、title、credits）。
instructor：包含属性（ID、name、salary）。
section：包含属性（course_id、sec_id、semester、year）。
student：包含属性（ID、name、tot_cred）。
time_slot：包含属性（time_slot_id、｛(day，start_time，end_time)｝）。

我们设计的联系集如下：

inst_dept：关联教师和系。
stud_dept：关联学生和系。
teaches：关联教师和开课。
takes：关联学生和开课，包含描述性属性grade。
course_dept：关联课程和系。
sec_course：关联开课和课程。
sec_class：关联开课和教室。
sec_time_slot：关联开课和时段。
advisor：关联学生和教师。
prereq：关联课程和先修课程。

你可以验证没有任何一个实体集包含由联系集造成冗余的属性；另外，你可以验证此前在大学数据库关系模式中的所有的信息（除了约束）全部包含在上述的设计中，只是关系设计中的几个属性被E-R设计中的联系所替代。

3. 总结

数据库设计主要涉及数据库模式的设计。实体-联系（Entity-Relationship，E-R）数据模型是一个广泛用于数据库设计的数据模型。它提供了一个方便的图形化表示方法以查看数据、联系和约束。
E-R模型主要用于数据库设计过程。它的发展是为了帮助数据库设计，这是通过允许定义企业模式（enterprise schema）实现的。这种企业模式代表数据库的全局逻辑结构，该全局结构可以用E-R图图形化表示。
实体（Entity）是现实世界中存在并且区别于其他对象的对象。我们通过把每个实体同描述该实体的一组属性相关联来表示区别。
联系（relationship）是多个实体间的关联。相同类型的联系的集合为联系集（relationship set），相同类型的实体的集合为实体集（Entity set）。
术语超码（superkey）、候选码（candidate key）以及主码（primary key）同适用于关系模式一样适用于实体和联系集。在确定一个联系集的主码时需要小心，因为它由来自一个或多个相关实体集的属性组成。
映射的基数（mapping cardinality）表示通过联系集可以和另一个实体关联的实体的个数。

《数据库系统概念》——实体-联系模型相关推荐

数据库系统概念笔记-关系模型介绍
转载自数据库系统概念笔记-关系模型介绍作者 CyninMa 数据库系统概念笔记-关系模型介绍 2.1 关系数据库的结构关系数据库由表(table)的集合构成,每个表有唯一的名字.例如,inst ...
实体联系模型mysql_数据库系统概念读书笔记――实体-联系模型_MySQL
bitsCN.com 数据库系统概念读书笔记--实体-联系模型前言为了重新回顾我写的消息系统架构,我需要重新读一下数据库系统概念的前三章,这里简单的做一个笔记,方便自己回顾基本概念实体-联系( ...
数据库系统概念总结：第七章数据库设计和E-R模型
周末无事水文章,期末备考的总结资料第七章数据库设计和E-R模型 7.1 设计过程概览 7.1.1 设计阶段需要完整地刻画未来数据库用户的数据需求选择数据模型,并采用所选数据模型的概念将这些需求 ...
【数据库系统原理】实体-联系模型
实体-联系模型文章目录实体-联系模型一.实体和实体集 (1)实体的基本概念 (2)实体集的基本概念二.联系 (1)联系的基本概念 (2)联系的类型 (3)联系的属性三.实体联系图 (1)实体 ...
数据库系统—实体联系模型
实体联系模型数据库设计的六个阶段需求分析阶段概念结构设计阶段逻辑结构设计阶段数据库物理设计阶段数据库实施阶段数据库运行和维护阶段实体联系模型用实体表示事务,用联系表示物体之间的联系概 ...
数据库系统——第三讲关系模型之基本概念
数据库系统--第三讲关系模型之基本概念什么是关系模型什么是关系关系有什么特性候选码与外码关系模型的完整性小结什么是关系模型重点与难点:一组概念的区分:围绕关系的相关概念,如域.笛卡尔 ...
数据库系统概念—学习笔记1
第1 章引言 1.数据库管理系统( DataBase-Management System , DBMS ):由一个互相关联的数据的集合和一组用以访问这些数据的程序组成.这个数据集合通常称作数据库( ...
实体联系模型mysql_数据库实体联系模型与关系模型
需求分析阶段主要分析项目涉及的业务活动和数据的使用情况,弄清所用数据的种类.范围.数量以及在业务活动中的存储情况,确定用户对数据库系统的使用要求和各种约束条件等,形成数据库需求说明书. 概念结构设计阶 ...
数据库实体联系模型与关系模型
数据库设计是指根据用户的需求,在某一具体的数据库管理系统上,设计数据库的结构和建立数据库的过程.例如,编程微课是在线编程教育项目,该项目涉及到课程.学生.老师.学习资料等数据,这些数据都要被存储下来, ...

《数据库系统概念》——实体-联系模型