精华内容
下载资源
问答
  • 2020-05-18 20:03:34

    弱实体的相关概念

    相关文章1

    相关文章2
    一篇比较好的讲解弱实体的博客

    比如用户 和消费记录, 消费记录的 id 和 用户的 id 做成联合主键 唯一标识消费记录 这个实体,那么 消费记录是依附于用户实体而存在的,(先有用户,才有消费记录) 所以消费记录是弱实体,而用户则是强实体。

    强实体和弱实体一般是 1:N 或者 1:1 的关系,弱实体依赖强实体而存在(依赖强实体的主键)

    更多相关内容
  • 目录写在最前一、 强实体与弱实体的定义1. 强实体2. 弱实体百度百科中的解释《数据库系统课程》中的解释总结起来 写在最前 数据库设计是困难的,其原因之一就在于我们很难去完全把握实体的定义。是不是实体、该不该...

    写在最前

    数据库设计是困难的,其原因之一就在于我们很难去完全把握实体的定义。是不是实体、该不该定义实体是一直困扰数据库初学者的问题,强实体、弱实体的概念同样难以理解。
    我一直深受强实体、弱实体概念的困扰,百度百科中的定义不能很好地解决我的困惑,一路学习过来,自己对强实体、弱实体的理解越来越深入,因此写下这篇文章与大家分享自己对强实体与弱实体的一些体会。如果觉得有帮助,请点赞鼓励!

    一、 强实体与弱实体的定义

    1. 强实体

    其实例的存在不依赖于任何其他实体类型的实例;有自己独立的主键,唯一性地标识它的每个实例。

    2. 弱实体

    百度百科中的解释

    一个实体对于另一个实体(一般为强实体,也可以是依赖于其他强实体的弱实体)具有很强的依赖联系,而且该实体主键的一部分或全部从其强实体(或者对应的弱实体依赖的强实体)中获得,则称该实体为弱实体。

    《数据库系统课程》中的解释

    其实例的存在依赖于其它实体类型的实例;其主键包括它所依赖的实体类型的主键。

    总结起来

    百度百科中的解释和课程中的解释都是在强调两点:
    第一点:依赖,弱实体应该依赖于强实体;
    第二点:主键,弱实体的主键应该是组合主键(其他实体的主键组成的)。

    二、 关于定义的几个疑惑

    但定义中有几个地方令我不解,我相信初学者多少也会遇到同样的问题。我总结了四点:

    什么叫“依赖”?

    以教务系统数据库为例,如果没有学校,那么学院不再是学院,学生不再是学生,课程更将不复存在,所以这些实体都依赖于其他实体,因此这些都是弱实体?但我们知道,学院、学生一般都作为强实体。因此,定义中的“依赖”指的是什么呢?

    先有鸡还是先有蛋?

    是因为一个实体的主键包括其他实体的主键而使该实体成为了弱实体,还是因为一个实体是弱实体,所以它的主键必须包括其他实体的主键?
    这是一个先鸡(弱实体)还是先蛋(组合主键)的问题。

    为什么要定义弱实体?

    我们知道,弱实体对于另一个实体具有很强的依赖联系,似乎并不是“真实”存在的事物,那么为什么我们还会有弱实体的概念,而不是直接认为实体就是强实体呢?

    什么时候需要定义弱实体?

    有时候弱实体就是需求中的实体,只是它依赖于其他实体,有时候关系也可以认为是弱实体,有时候出于设计的需要我们也会定义弱实体,那么何时需要定义弱实体?

    总结起来,以上四个问题其实是一个问题:

    怎样正确地理解强实体与弱实体的含义?

    三、 唯有实践,方出真知

    有很多事情是很难想明白的,但经过几次数据库设计实战,我发现自己或多或少地定义了一些弱实体。我选取了三个典型的例子:

    教务系统数据库设计(一)

    之后我会专门写一篇博客介绍教务系统数据库的设计过程,这里选取其中一个比较典型的部分。业务需求是这样的:

    一周有七天,每一天有11节。

    上面这句话中涉及到了几个实体?很简单吧,三个实体:周、天、节。那么它们是强实体还是弱实体呢?不好说,但是我们可以确定,概念数据模型的设计应该是这个样子:
    在这里插入图片描述
    需要勾选“Dependent”。首先回答一个问题:为什么不能是下面这个样子?
    在这里插入图片描述
    Day的主键应该是dayOfWeek,如果不用“Dependent”将Day的主键改为weekNum+dayOfWeek,我们的Day表格中只能有七行记录,也就是说对于某一个星期一,我们无法区分这是第几周的星期一!同样的道理,如果Section的主键仅仅为sectionNum,那么我们根本无法区分这一节课是哪一天的课!教务系统要有排课、选课功能,只知道第1节,但不知道是哪一天的第一节,这肯定是不可以的。

    因此,当我们想要找到某一节时,需要同时指定那一周、星期几、哪一节。比方说我可以把《数据库设计》这门课安排在第一周星期一三四节。

    在这个例子中,三个实体都是需求中明明白白告诉我们的实体,但我们将Day与Section都作为了弱实体,因为强实体的Day与Section根本无法满足需求。

    培训公司数据库设计

    业务需求是这样的:

    每位学生每期只能参加一门课程。

    言外之意,公司有很多课程。我们只分析“每位学生每期只能参加一门课程”这一需求,发现涉及到两个实体:学生、课程。所以我们或许会想当然地这样去设计数据库:
    在这里插入图片描述
    一个课程可以由多个学生选择,一个学生只可以选择一门课程。发现问题了吗?业务需求里不是说一个学生只能参加一门课程,而是说一个学生在一期只能参加一门课程!这么设计数据库是在断人家财路。因此,我们必须考虑“每期课程”这个概念:在这里插入图片描述
    看样子似乎是没问题了,但是数据库设计是不可能这么容易就没问题的。我们把每期课程都作为一个记录,那么对于课程的信息,比方说课程名称、价格、介绍,每开一期课就要向数据库中存一行记录,因此我们的数据库会出现大量冗余(也就是说不满足数据库第二范式)。因此,我们应该这样去设计数据库:
    在这里插入图片描述
    看到了吗?这里的“Record”是一个弱实体,它的主键是“学期主键+学生主键”,代表学生参加课程这一行为,抽象成为了弱实体。为什么要用学期表的主键和学生表的主键呢?因为一个学生、一个学期,那么就只能参加一门课程了,所以根据主键唯一标识每行记录的原则,应该这样去选取。课程表的主键成为了Record表的外键,课程表与Record表之间存在一对多关系。

    在这个例子中,学生、课程是业务需求描述中显而易见的实体,“期”也可以认为是比较明显的实体,但“参加”这个动词在我们的数据库中便成为了“参加记录” ,也就是Record实体。

    教务系统数据库设计(二)

    这一部分的业务需求是这样的:

    老师授课。

    似乎业务需求很简单,但事实上,多位老师可以独立上同一门课,也可以共同上同一门课。一位老师可以参与多门课的授课。真实的教务系统的确是这个样子的。一般,像马原、高数等课程是多位老师独立授课,专业核心课大多是多位老师共同为同一班级授课。那么数据库要怎样设计呢?
    在这里插入图片描述
    像这样吗?老师、课程之间建立多对多关系?不难发现,这样的多对多联系无法区分上面所说的两种授课情况。也就是说,我们必须引入第三个表,才有可能实现业务需求,两张表格是行不通的。我是这样设计的:
    在这里插入图片描述
    在课程表与老师表之间,引入了新的一张表格——排课表。一个课程可以安排多次排课,一个排课就对应一个独立的授课安排,可以由一位老师完成,也可以由多位老师完成。那么像马原授课这种多位老师独立授课的情况该如何解决呢?在排课表中,认为不同老师的马原课是同一课程(引用Course表中同一记录的主键作为外键),但是它们是不同的排课(ArangeNo不同,可能一个是1,另一个是2)。也正因如此,排课表的主键是组合主键(课程编号+排课编号,如CS163、1)。

    这个例子中,需求中并没有提“排课”这一实体,这个实体完全是我们为了满足需求而定义的,甚至它和课程表在概念上还有点关系。注意到了吗,这里的“关系”就是弱实体概念中所说的“依赖”!

    四、 对强实体与弱实体的总结

    1. 区别弱实体与强实体的关键在于主键,“依赖”的实质是主键之间的关系。所以归根到底,就一个主键之间是否有关系、主键是否是组合主键的问题。

    2. 弱实体与强实体可以相互转换,没有绝对意义上的强与弱。既然区别弱实体与强实体的关键在于主键,那么一个同样意义的表,当我给它一个编号作为主键,那么它就不是弱实体,而如果我令它的主键是组合主键,它就是弱实体。就像刚刚,我们说排课表的主键是组合主键(课程编号+排课编号,如CS163、1),所以它是弱实体,那么如果我定义排课编号是“CS16301”,而不再是“1”,那么它的主键(排课编号)就不再需要课程编号,它就成为了强实体。

    3. 弱实体也可以依赖于弱实体。就像第一个例子中的Session,它依赖于Day,Day就是一个弱实体。

    4. 弱实体与它所依赖的实体之间的关系只能是1:1或n:1。也就是说,一个弱实体实例不可能依赖于同一实体的多个实例。这个其实很好理解,因为如果弱实体实例A依赖于实例B,那么A的主键要包括B的主键,所以A当然不可以依赖于很多个B。

    5. 业务需求决定弱实体的定义,分三种情况:

      情况一、 业务需求中明确的弱实体
      情况二、 业务需求中隐含的弱实体
      情况三、 业务需求中无、但为实现业务需求不得不定义的弱实体

      如果觉得这篇文章对你有帮助,请给博主点个赞!

    展开全文
  • 数据库中,设计的ER图里面弱实体A依赖于弱实体B的话,是否需要将弱实体B中的主键放去弱实体A中充当主键
  • 在实践中,这意味着父母的主键被迁移到子PK的子集(通常是proper)中(术语“弱实体”通常与主键相关地定义,但理论上它可以应用于任何键).拥有一个不能独立存在的实体是完全合法的,但可以独立识别 – 换句话说,就是与非...

    一个实体并不弱,因为它不能独立存在,而是因为它无法独立识别.因此,“引导”到弱实体的关系称为“识别”关系.在实践中,这意味着父母的主键被迁移到子PK的子集(通常是

    proper)中(术语“弱实体”通常与主键相关地定义,但理论上它可以应用于任何键).

    拥有一个不能独立存在的实体是完全合法的,但可以独立识别 – 换句话说,就是与非NULL的非识别关系.

    您必须要问:historyLineID可以单独使用,还是与orderID结合使用?我怀疑后者就是这种情况,这会使它成为一个弱势实体.

    Is this really a correct weak entity relationship?

    你告诉我们的不是一个弱实体 – 父母的PK不会迁移到孩子的PK中.

    Is there other ways to identify them?

    你基本上有两个选择:

    > orderHistory有一个复合PK:{orderID,historyLineID},其中orderID是FK.顺便说一句,这个PK可以被认为是“自然的”:

    > orderHistory有一个代理PK:{orderHistoryID},而orderID在PK之外.您仍然需要备用密钥{orderID,historyLineID}:

    Should I add the PK of table order to table orderHistory and make it a composite primary key?

    是的,这是上面描述的第一个选项.除非你在orderHistory本身有子关系,否则这也是最好的解决方案.如果orderHistory确实有孩子,那么这可能是也可能不是最佳解决方案,具体取决于几个因素.

    What if I decide to model this as a normal One-To-Many relationship where orderID is added as a foreign key instead? what are the cons of doing so?

    这不是 – 或者.字段可以是FK和(主要或备用)键的一部分,如上所示.

    Will ignoring Weak entities at all cause any problems later in a design provided all tables are in 3rd normal form?

    除非您正确指定密钥,否则您将无法达到3NF,如果不考虑哪个实体可以独立识别,哪个不能独立识别,您将无法做到这一点.

    展开全文
  • 文章目录4.4 弱实体集定义弱实体集的来源弱实体集的要求弱实体集的符号弱实体集的设计4.5 从 E/R 图到关系设计E/R 联系到关系的转化两个基本规则 和 特殊处理实体集 -> 关系非弱实体集 -> 关系弱实体集 -> ...

    4.4 弱实体集

    定义

    实体集 E 的所有属性集均不能独立成键,

    键中必须包含另一实体集 F 的键

    则E是弱实体集。


    弱实体集的来源

    1. 层次结构,但不是 isa 联系。

      (如果 isa 联系中丢弃了根的键,则其也可能成为弱实体集)

    2. 连接实体集(是弱实体集)。

      因为,连接实体集本身指代 连接关系 ,本质上不是真正意义上的实体;

      所以,连接实体集的键必须借助于相关实体集


    弱实体集的要求

    • 弱实体集 E 的键包括:

      • 0个或多个自有属性(可以没有)
      • 通过 E 的支持联系(从 E 引出,到达其他实体集的多对一联系)的键

    • 设 R 是从 E 到 F 的多对一联系,则 R 是 E 的支持联系的条件是:

      • R 必须是从 E 到 F 的二元联系

      • 引用完整性,即 R 到 F 是圆箭头。

      • E 的键中所包含的 F 的属性 必须是 F 的键

        示例见“弱实体集中的符号”


    • 从弱实体集引出的多对一联系(假设从 E 到 F)不一定都是双边菱形,取决于 F 是否是其支持联系。

    • 弱实体集具有传递性:F 也可能是弱实体集,其支联系仍然可以是弱实体集。

    • 若 E 到 F 有多个不同的支持联系,则 E 中的键会包含多个 F 的键的拷贝。但其取值不一定都相同。


    弱实体集的符号

    • 双边菱形:多对一关系的支持联系

    • 双边矩形:弱实体集

    在这里插入图片描述


    弱实体集的设计

    • 一般做法:每个实体集都尽量设计自身有实际意义的 ID 属性。

      当一个实体集的所有 有意义的属性 都不能作为 ID 时,再将其设为弱实体集。

      如果要求不能含有弱实体集,则可以为弱实体集增加一个无意义的 ID 属性作为主键。


    4.5 从 E/R 图到关系设计

    必要性等见书P92。

    E/R 联系到关系的转化

    两个基本规则 和 特殊处理

    • 两个基本规则:

      1. 把 每个实体集 转化为 具有相同属性集合的关系。

      2. 用关系替换联系:

        关系的属性就是 联系所连接的实体集的键集合联系自身的属性。(自身的属性 + 连接的实体集的键属性集)

    • 特殊处理:

      • 弱实体集(不可直接转化为关系)。
      • isa 联系 和 子类。
      • 关系的合并。

    • 具体到属性和重名问题

      设一个 E/R 联系为 R,则其转化后的关系中:

      • 属性

        • 包含联系 R 涉及的每一个实体集的键属性(或键属性集)
        • 包含联系 R 本身的属性(如果存在)
        • 如果一个实体集在联系 R 中有多个角色,则其出现的次数等于角色的次数,转换为关系时需要重命名(避免重名)
      • 重名问题

        如果 R 本身的属性 和 与其相连的实体集的键属性 有同名,需要重命名。


    实体集 -> 关系

    非弱实体集 -> 关系

    对任意一个非弱实体集,创建一个同名且具有相同属性集的关系即可。


    弱实体集 -> 关系

    设弱实体集为 W。

    • 要点

      • W 转化得到的关系不仅包含自身属性,也包含相应的支持实体集的键属性

        • 支持实体集的辨认(E/R 图中):由从 W 引出的双边菱形(表示支持联系)连接。
      • 与 W 相连的联系,经过转化后得到的关系必须包含 W 的键属性 和 对 W 的键有贡献的实体集属性

      • 支持联系(即从W 指向 支持实体集 的联系)不必转换为关系。

        因为该关系可以通过 关系组合方法 得到。

        而在不考虑支持联系 R 的本身属性时,组合得到的关系就是 W 的关系。

    • 修改规则

      • W 转化为关系后的模式组成为:

        • W 的所有属性

        • 与 W 相连的支持联系的所有属性

        • 对于每一个连接 W 的支持联系(从 W 到实体集 E 的多对一联系),要包含 E 全部的键属性

          根据前面的要点:W 转化得到的关系不仅包含自身属性,也包含相应的支持实体集的键属性

      • 注意:不要为 与 W 相连的支持联系 构造关系


    • 带有子集模式的关系

      即使当 R 的属性集是 S 的属性集的子集,也不一定能消除 R:

      • S 的附加属性不允许把 R 的一个元组扩张到 S 中。

        书上的例子:税收对象和普通人。

        TaxPayer(name, SSNo, amount)

        People(name, SSNo)

        People 中的一些人可能并没有收入,所以不能加入 TaxPayer 中。

      • 即使 R 和 S 具有相同的属性集,也可能不等价。

        Stars(name, addr)

        Studios(name, addr)

      • (反过来看)由弱实体集和支持联系得到的关系,由于内在的支持约束,可以保证元组间的一一对应关系,所以可以消除。


    关系组合

    提出背景:有时,从实体集和联系转化而来的关系不一定最优。

    设有关系 E 和 R,

    • E 和 R 合并的基础:

      如果存在 E 到 F 的多对一联系 R,则按照转化规则,直接转化后得到的 关系模式 E(由实体集转化,显然 E 中必然包含自己的键属性)和 R(由联系转化)都含有实体集 E 的键属性。

    • E 和 R 合并时分别保留的内容:

      关系模式 E 中还包含实体集 E 的非键属性,

      关系模式 R 中包含 F 的键属性和联系 R 中的所有属性。

    • 由于 R 是从 E 到 F 的多对一联系,所以根据 E 的键就可以确定以上属性,两个关系合并时不会产生冗余。

    • E 和 R 的组合

      设 R 是 E 到 F 上的多对一关系。

      则:

      • 组合后的模式包括:

        • E 的所有属性
        • F 的键属性
        • R 的所有属性
      • 根据多对一关系的定义,E 中的实体 e 可能找不到与其相连的 F 的实体,此时用空值

        如图所示,
        在这里插入图片描述

      • 注意:如果联系是多对多的,则不能直接组合。可能会产生冗余

        例:
        在这里插入图片描述
        在这里插入图片描述
        在这里插入图片描述


    4.6 子类结构到关系的转化

    三种转化策略

    • E/R 方式转化:每个实体集对应一个关系;
    • 面向对象方法:每个包含根的实体集子树对应一个关系;
    • 空值法:创建一个包含层次中所有实体集的属性的关系,每个实体由一个元组表示,对于实体没有的属性则该元组的相应分量为空。

    1. E/R 方式转化

    • 方式:给每一个实体建立一个关系。

      每个实体集对应的关系都包含根的属性集实体集本身的属性

    • 注意:isa 联系与其他不同(isa 连接的是单个实体的分量,而不是不同的实体),不能为 isa 创建关系。


    • 示例:

      在这里插入图片描述

      上图转化为

      Movies(title, year, length, genre)

      MurderMysteries(title, year, weapon)

      Cartoons(title, year)

      联系 Voices 转换为

      Voices(title, year, starName)

      starName 是 Stars 的键属性。


    2. 面向对象方法

    • 方法:枚举所有包含根的子树,为每一个子树建立一个关系,该关系模式中包含子树中所有实体集的所有属性。


    • 示例:

      图同上,所有包含根(Movies)的子树如下:

      • Movies
      • Movies, Cartoons
      • Movies, MurderMysteries
      • Movies, Cartoons, MurderMysteries

      对应的关系模式:

      Movies(title, year, length, genre)
      MoviesC(title, year, length, genre)
      MoviesMM(title, year, length, genre, weapon)
      MoviesCMM(title, year, length, genre, weapon)
      ---
      还有Voives(title, year, starName)
      
      • 上例中,Voices 的处理:
        • 若 Voice 是从 Cartoons 引出的多对一联系,则可以在 MoviesC 和 MoviesCMM 中增加一个 voice 属性。
        • 若其是多对多联系,则转化为关系。

    3. 空值组合关系

    • 方法:

      构造一个大关系,其包括全体实体集的所有属性。

      一个实体(不论层次)对应一个元组,该实体没有的属性元组分量,置空即可。


    • 示例:

      图同上,

      Movies (title, year, length, genre, weapon)


    三种转化策略的比较

    • 支持一般查询的角度:空值法

      因为所有的属性都在一个大关系中。

    • 空间占用情况:面向对象 < E/R 方式 < 空值法。


    • 对于面向对象方法,如果一个根有 n 个孩子(一共两层),则共有 2 n 2^n 2n 个实体类。

      包含0个孩子的实体类:1 (即 root)

      包含1个孩子的实体类:n (root + child1 || … || child n)

      包含 n 个孩子的实体类:1

      Num = C n 0 + C n 1 + ⋯ + C n n = 2 n \text{Num} = C_n^0+ C_n^1 + \dots + C_n^n = 2^n Num=Cn0+Cn1++Cnn=2n


    特殊查询方式下的比较

    • 仅涉及一个实体集内容的查询:E/R 法最优(每个实体集都有自己的关系)
    • 仅涉及根节点,面向对象方法最差(根节点元组被分散)
    • 涉及某一类子树,则面向对象最优(每一类都有子树对应)
    展开全文
  • 问题有两个一个是弱实体的建表应该怎么写? 我的解答思路和尝试过的方法 我找了一些资料是这样写的 CREATE TABLE primary_entity ( id numeric PRIMARY KEY, -- some data fields ); CREATE TABLE weak_entity ( id...
  • 在ER模型中,弱实体用双矩形框表示,联系则用双菱形(该弱实体依赖于实体而存在,则与实体的之间是1:*联系) 2.属性 在ER模型中,单值属性用椭圆形表示 在ER模型中,多值属性用椭圆形表示(会产生大量的数据冗余...
  • 实体关系模型 基础的 ER 建模概念 实体:某类事物,区别于其他事物。实体具有属性(attribute)。一个人可以是一个实体,一只猫也可以是一个实体,人之所以区别于猫,是因为人具有很多猫不具有的属性 实体集:一类...
  • 弱实体转换关系表 非标识符依赖弱实体:原标识符作为主键,依赖对象的标识符作为外键 标识符依赖弱实体:依赖对象的标识符作为主键和外键,原标识符作为主键,构成复合键 实体关系转换参照完整性 1:1 : 选一个实体(1)的...
  • 数据库主键代码pk

    2021-01-21 15:43:28
    一、JPA通用策略生成器 通过annotation来映射hibernate实体的,基于annotation的hibernate主键标识为@Id, 其生成规则由@GeneratedValue设定的.这里的@id和@GeneratedValue... 文章 ap0581w9c 2009-06-12 739浏览量 ...
  • 模式保持内模式不变 erp实施顾问笔试题篇2 1:在关系模式R(A,B,C)中,有函数依剌集F={(A,B)→C,(B,C)→A},则R最高达到 A.INF B.2NF C.3NF D.BCNF 2:将弱实体转换成关系时,弱实体的主码 A.由自身的候选关键字组成 B...
  • 6 数据库设计:实体-联系方法

    千次阅读 2022-01-10 16:01:00
    6 数据库设计:实体-联系方法 数据库的设计方法和生命周期 数据库设计方法 ① 实体-联系方法 ② 属性-联系方法 实体-联系方法 围绕实体展开 经历需求分析、概念设计、物理设计、数据库实现、运行维护等阶段 先建立...
  • 概念设计(Conceptual Design) —— 设计实体关系模型 (ER Model) 逻辑设计(Logical Design)—— 实现从 ER 模型到关系模式(Relation Schemas)的转换。 物理设计(Physical Design) 本文主...
  • 文章目录2.1、实体类2.2、持久化字段和属性2.2.1、例子2.3、Access type (访问类型)2.3.1、默认访问类型2.3.2、显式访问类型2.3.3 内嵌类的访问类型2.3.4、内嵌类的默认访问类型和映射超类2.4、主键实体身份2.4.1...
  • 第八章 ER建模 实体联系建模

    千次阅读 2021-05-14 17:28:15
    Entity-Relationship Modeling – 实体联系建模 1 .实体类型 1.1 实体类型 定义:被企事业单位认可的、能够独立存在的一组具有相同属性的对象 ER模型的基本概念是实体类型,实体类型代表现实世界中具有相同属性的一...
  • 主键 :primary key 外键:foreign key 非空约束: not null 检查约束条件 : default 值 check(条件) 唯一约束 : unique 具体含义: 数据库-主键和外键及其约束 1:什么是主键  在一张表中,用来唯一标识一条...
  • 数据库复习(4) 实体关系模型

    千次阅读 2020-07-14 16:30:39
    实体集(Entity Sets) ...举行代表实体集,上方为名字,下方是属性,主键用下划线标出 菱形代表关系集 线段连接实体集和关系集 虚线连接一个关系集和它的描述属性 双线表示实体集对于关系集的全参与 双菱形表示
  • 文章目录一,实体集1,实体集表示为表2...E-R 图1,E-R 图1.2 角色2,具有三元联系的E-R图3,二元与非二元联系4,弱实体集七,扩展的E-R特性1,特化与概化2,对特化/概化的设计约束3,聚集4,E-R图表示法中使用的符...
  • 实体关系图 (ERD) 指南

    千次阅读 2021-12-23 16:08:00
    在本指南中了解有关实体关系图 (ERD)、它们的用途、如何理解它们、如何创建它们等的所有信息。 实体关系图 (ERD) 是一种图表,可让您查看不同实体(例如人员、客户或其他对象)在应用程序或数据库中如何相互关联。 ...
  • 数据库期考考点

    2020-06-19 00:02:55
    弱实体集合:形成它的主键需要关联的其他实体的主键,即它的主键包括外键。 第二题 3NF和BCNF范式 判断无损连接和保持函数依赖的分解 属性闭包求键 1. 3NF的判断 X->A:X不是superkey且A不是prime时,...
  • 主键如果是由多个属性构成,又称联合主键。 主属性:属于某个候选码的属性。 非主属性:不属于任何候选码的属性。 表的域、属性、字段、数据项是一致的。 关系数据库中的依赖:根据A属性可以得到B属性,则B属性...
  • 外键约束 以及 数据库中实体的对应关系(1==1,1==n,n==n) 1.1.1 外键约束Create database day16;Use day16;创建部门表:create table dept(did int primary key auto_increment,dname varchar(20));insert into ...
  • 数据库实体关系模型 --- ER Model

    千次阅读 2021-10-05 15:13:58
    数据库实体关系图 --- The Entity-Relationship Model: ER ModelER模型的基本组成E-R diagram的基本组成ConstraintsKey constraintsParticipation ConstraintsEntity or AttributeKeysweak entity set三元关系 --- ...
  • 一.一对一关联实体的配置(单双向的关联) ...1. 一对一主键关联(主键同时作为外键) 2. 一对一外键关联(外键手动设置为Unique属性) 一点小复习 [此处为经典的数据库关系图] 编写一对一关系对象的代码 在这里
  • 四、弱实体 五、步骤 1、新建 2、类别->软件和数据库 3、选择Chen‘s数据库表示法 4、开始绘图 一、E-R图简介 E-R图也称实体-联系图(Entity Relationship Diagram),提供了表示实体类型、属性和联系...
  • 一个实体的存在必须以另一个实体的存在为前提,前者被称为弱实体,后者被称为强实体。 标识符依赖弱实体:成绩实体的标识符取决于学生实体和课程实体的标识符。 非标识符依赖弱实体:订单实体的标识符不取决于客户...
  • 数据库设计4-概念结构设计

    千次阅读 2022-03-28 17:47:26
    其定义为一个实体对于另一个实体(一般为强实体,也可以是依赖于其他强实体的弱实体)具有很强的依赖联系,而且该实体主键的一部分或全部从其强实体(或者对应的弱实体依赖的强实体)中获得,则称该实体为弱实体。...
  • 数据库基础知识

    2017-11-02 14:44:36
    弱实体主键的一部分或全部从被依赖实体获得。如果y被删除,那么x也要被删除。从属实体的集合便称为 弱实体集 。弱实体在ER图里用双线矩形表示。比如某单位的职工子女信息,如果职工不在该单位了,其子女信息也没有...
  • PowerDesigner中的CDM设计的外键作主键

    千次阅读 2012-10-12 21:49:16
    CDM里好像没有外键,我是说转换成PDM之后,外键又要做表的主键,在对应的CDM里是怎么设置的? 双击关系,在弹出的Relationship Properties窗口中选择Detail选项,然后将Dependent复选框选中,即可。 使用...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,045
精华内容 2,818
关键字:

弱实体的主键

友情链接: graphics.rar