精华内容
下载资源
问答
  • PowerDesigner的概念模型中实体之间的关系是非常重要的,也决定了从概念模型转化到物理模型时的表现形式,所以有必须深究其中的相关设置。做数据库重要的就是表与表之间的关系,而这个关系是连接所有数据库系统...

    在PowerDesigner的概念模型中,实体之间的关系是非常重要的,也决定了从概念模型转化到物理模型时的表现形式,所以有必须深究其中的相关设置。做数据库重要的就是表与表之间的关系,而这个关系是连接所有数据库系统的纽带,所以即使我们不用PD,也应该重视表与表之间的关系。这也是关系型数据库的由来。

    PD中的表与表之间的关系有四种,分别是one-one(一对一),one-many(一对多),many-one(多对一),many-many(多对多)。在实际中使用得最多的只有前面两种,而多对一和一对多其实没有什么区别,只是二者关系的反向描述,所以其可以看成是一种类型。而多对多在实际的数据库设计中也是时有出现的,这种情况下,我们一般不直接处理多对多的关系,而是通过一种技巧,将多对多转化为多对一,和一对多的关系,这样可以简化数据库关系的复杂性。将多对多转化为多对一,再一对多意思是通过提供一个关联关系表,来使多对多的关系表与该关联关系表发生关系,而不让其直接发生多对多的关系,这样就可以简化这样的关系。前面文章中已经说明如何创建这种关联表了。这里也就不再说多对多的关系。后面只重点说明一对一,一对多的关系。

    在CDM中,实体之间的关系更符合现实情况一些,以一对多的关系来说,如果一个实体对应多个实体,通常含有“包含,拥有”等这样的意思在里面。比如一个部门拥有多个员工,一个企业拥有多个部门等。而如果多个实体对应一个实体,则通常含有“属于,包含于”等这样的意思。比如多个员工属于一个部门,多个部门包含于一个企业等。在PDM中就很具体了,且与实际的有些区别了,这主要是由于在软件的实现角度上的体现,比如一对多的关系,比如T1与T2的关系为T1一对多个T2,在PDM中,通常表现在T2中有一个外键,用来存储T1的主键,这样就叫一对多,而这样的表现与实际上具有一定的差别。当然这是没有什么问题的,因为PDM才是我们真正在软件实现时所采用的方式。我只是想说的是CDM中这种关系的描述,可能更和实际情况接近一些,也就更加容易明白一点。

    好了,下面分别说明一下一对多和一对一的关系详细说明:

    1.对于一对多的说明

    当两个实体需要进行一对多的关联时(比如T1与T2的关系为T1一对多个T2,T1和T2为两个实体),我们通过Relationship,从T1拉至T2时,二者关系就建立起来了。默认情况下就是个一对多的关系,即T1为1,T2为多。

    双击拉的关系线,则弹出二者关系描述的对话框,我们就可以在这个弹出的属性对话框里进行我们所需要的设置了。在弹出来的默认属性为General属性选项。我们可以在这个属性页里面修改关系名称以及对这个关系的描述等。点击Cardinalities属性页,在上面默认显示的就是一对多的关系,我们现在是描述一对多的关系,所以不修改它。在关系下面有个Dominant role,这个右边有个下拉框,不过是被置灰了,不可操作,这里先不管,后面在说一对一时再说说这里。

    在T1 to T2的内容里面,有个Role name,在其右边有个输入框,可以输入T1表的角色名字,这里就可以用前面提到的比如“拥有,包含”等这样的内容,可以用来说明T1表的职能。在Role name下面的Dependent默认是置成灰色,意即不可操作,这里我们就不管了。然后是Mandatory,这个是什么意思呢?这个是否选择决定了某个东西是否为空。是什么东西呢?指的是和本实体发生关系的对方实体的主键在本实体的外键字段是否为空。比如现在有种情况是T1中某个字段,如par1,该字段为外键,它将存储T2中的主键,则如果Mandatory被选中,则par1不为空,意即它必须存储某一个T2的值,而如果不选上,则表示该字段值可以为空。在现在的情况下T1与T2是一对多的关系,我们知道在PDM中,出现的情况是T2中会生成一个外键,用来存储T1表的主键,而T1表不会有任何字段来存储T2的主键 ,所以这个Mandatory是否被选择上,不会对关系造成任何影响,所以这里我们就不用管它了。当然,我们从实际的描述中,可以这样来说明这个值的选取相关的情况,比如现在T1指的是部门,而T2指的是员工,当你选择了该值,则在后面的Cardinality中会变成1,n,即如果选择这个值,则表示一个部门至少有一个员工,而如果不选,则表示一个部门至少有0至n个员工,就这个区别,因为为一对多,T1表中不会存储T2表中的主键,即使你选择了Cardinality,用于说明是部门至少含有1个员工,但是,T2表此时仍为空,没有任何员工,也不会出现问题的(这是因为一对多这个关系,导致T1表中不会有T2的任何相关信息造成的,当然在一对一的关系中,则不一样的,后面会说到)。

    现在再说说T2到T1的内容里面的东西,其中的role name仍可以加入你所描述的T2的角色职责,比如“属于,包含于”等。在其下面,我们发现Dependent没有置灰了,是可以勾选的。我们先不管它,先趁热把Mandatory再说清楚点,此时由于我们已经知道T2表中会含有T1的主键的了,因为一对多的关系,则在生成的T2表时,会生成一个外键,用来单独存储T1的主键的,现在有个问题出现了,就是T2的存在是否依赖于T1,即说白一点就是一个员工是否一定要属于某一个部门?如果你的数据库系统中要求一定属于,那么你就把Mandatory选择上。反之,如果你认为新来的员工还没有分配好部门,可以暂时不让其属于某一个部门,到后面在人为的选择某一个部门,那么你就可以不用选择上Mandatory了。Cardinality会根据你是否选择Mandatory来决定其值是0,1还是1,1,意思很明确,就是是否T2一定属于T1,即一个员工是否一定属于一个部门。为这进一步确认Mandatory是否选中对PDM的实际表现造成的影响,可以通过CDM转化为PDM,查看其中的外键字段是否允许为空就可以明确了,如果你选择了Mandatory,则在PDM中T2生成的外键中将不允许为空,即必须含有T1的某一主键,而如果不选择Mandatory,则在PDM中T2生成的外键是可以允许为空的。

    好了,现在来说说Dependent的意思,如果其不选,则没有什么变化,如果其被选择中了,则会在PDM中对T2中生成的用于存储T1主键的那个外键(FK)将会成为T2的另外一个主键,这就是这个值的意思,如果你不需要T2中的外键同时成为主键,则不用选择该值。通常情况下,都不需要选择这个。

    2.一对一的关系说明

    在两个实体表中的关系中,如果一个表和另一个表是一对一的关系,这种一对一的关系有两种形式,以T1表和T2表为例。一种是T1中有个字段(外键)是T2表的主键,T2中有一个字段(外键)是T1表的主键,另一种情况是只有其中的一个表含有另一个表的主键,而另一个表不含有前一个表的主键。前面说的第一种情形是指两个实体互相感知,互相拥有对方的信息,另一种情况是指二者含有一定的依赖关系。某一个实体的存在依赖于另一个实体的存在。

    相对来说,在软件领域中,第二种情形更常见一些,完全平等的两个实体在现实中存在的意义不大,毕竟社会是一个充满着各种联系的实体,实体之间存在的着一定的依赖关系,就象孩子依赖于父母,员工依赖于企业,当然存在着两个互相感知的实体,这样带来的一个好处是在查询时非常迅速。下面说一下一对一关系的某些属性的改变带来的变化。

    当T1和T2实体建立好了关系之后,正如前面所言,默认情况下是个一对多的关系,我们这次就要改变这种关系了。在关系线的属性中,在Cardinalities属性页,我们将one-many修改为one-one,当我们选中one-one后,下面的Dominant role由原来的置灰不可操作状态变为可操作状态了。Dominant role的意思是占支配地位的角色,在其右边的下拉框中默认值为none,这里要求我们选择的是两个实体,谁占支配地位,谁占被支配地位。即谁支配谁。默认值中的none表示二者双方都不占支配地位,意即二者地位平等,则就是前面所述的第一种情况,即二者互相感知。这种情况下,在PDM中会发现T1表和T2表中都会生成一个外键,用于存储对方的主键。而下面的Dependent和Mandatory和前面描述一对多的关系时表现是一样的。这里就不再赘述了,只是需要注意的一点是如果你的关系是二者互相平等的话,在选择Mandatory中,不要将T1和T2都同时选择上,不然就会出现互斥现象,永远不成立。

    现在我重点说一下关于第二种情形,现在假设我们需要T2中的外键来存储T1的主键,那么这种情况下谁是支配地位的角色呢?在Dominant role中是选择T1->T2还是T2->T1呢?在->前面的是支配地位,后面的是被支配地位。想一下,为什么T2需要用一个外键来存储T1的主键呢?是因为T2需要T1的信息,需要T1来支持T2的存在,即T2依赖于T1,则说明T1应该是支配地位角色,那么在Dominant role项中,我们就需要选择T1->T2。明白了这个,就明白了为什么在一对多的关系里,这个Dominant role是置灰的呢?原因很简单,不需要我们指定这种支配角色,因为一对多的关系中,为一的那个必定是支配地位的角色,不需要我们改变。

    好了,关于实体之间的关系就结束了。如果你不是很确定关系的选项对后来的PDM造成的影响,你可以通过试验,通过简单的两个实体表,从CDM转化为PDM,实际看一下二者关系的表现,就明确了,这是我在实际的使用过程中,所用的方法。

    展开全文
  • PowerDesigner的概念模型中实体之间的关系是非常重要的,也决定了从概念模型转化到物理模型时的表现形式,所以有必须深究其中的相关设置。做数据库重要的就是表与表之间的关系,而这个关系是连接所有数据库系统...

    PowerDesigner的概念模型中,实体之间的关系是非常重要的,也决定了从概念模型转化到物理模型时的表现形式,所以有必须深究其中的相关设置。做数据库重要的就是表与表之间的关系,而这个关系是连接所有数据库系统的纽带,所以即使我们不用PD,也应该重视表与表之间的关系。这也是关系型数据库的由来。

    PD中的表与表之间的关系有四种,分别是one-one(一对一)one-many(一对多)many-one(多对一),many-many(多对多)。在实际中使用得最多的只有前面两种,而多对一和一对多其实没有什么区别,只是二者关系的反向描述,所以其可以看成是一种类型。而多对多在实际的数据库设计中也是时有出现的,这种情况下,我们一般不直接处理多对多的关系,而是通过一种技巧,将多对多转化为多对一,和一对多的关系,这样可以简化数据库关系的复杂性。将多对多转化为多对一,再一对多意思是通过提供一个关联关系表,来使多对多的关系表与该关联关系表发生关系,而不让其直接发生多对多的关系,这样就可以简化这样的关系。前面文章中已经说明如何创建这种关联表了。这里也就不再说多对多的关系。后面只重点说明一对一,一对多的关系。

    CDM中,实体之间的关系更符合现实情况一些,以一对多的关系来说,如果一个实体对应多个实体,通常含有“包含,拥有”等这样的意思在里面。比如一个部门拥有多个员工,一个企业拥有多个部门等。而如果多个实体对应一个实体,则通常含有“属于,包含于”等这样的意思。比如多个员工属于一个部门,多个部门包含于一个企业等。在PDM中就很具体了,且与实际的有些区别了,这主要是由于在软件的实现角度上的体现,比如一对多的关系,比如T1T2的关系为T1一对多个T2,在PDM中,通常表现在T2中有一个外键,用来存储T1的主键,这样就叫一对多,而这样的表现与实际上具有一定的差别。当然这是没有什么问题的,因为PDM才是我们真正在软件实现时所采用的方式。我只是想说的是CDM中这种关系的描述,可能更和实际情况接近一些,也就更加容易明白一点。

    好了,下面分别说明一下一对多和一对一的关系详细说明:

    1.对于一对多的说明

    当两个实体需要进行一对多的关联时(比如T1T2的关系为T1一对多个T2T1T2为两个实体),我们通过Relationship,从T1拉至T2时,二者关系就建立起来了。默认情况下就是个一对多的关系,即T11T2为多。

    双击拉的关系线,则弹出二者关系描述的对话框,我们就可以在这个弹出的属性对话框里进行我们所需要的设置了。在弹出来的默认属性为General属性选项。我们可以在这个属性页里面修改关系名称以及对这个关系的描述等。点击Cardinalities属性页,在上面默认显示的就是一对多的关系,我们现在是描述一对多的关系,所以不修改它。在关系下面有个Dominant role,这个右边有个下拉框,不过是被置灰了,不可操作,这里先不管,后面在说一对一时再说说这里。

    T1 to T2的内容里面,有个Role name,在其右边有个输入框,可以输入T1表的角色名字,这里就可以用前面提到的比如“拥有,包含”等这样的内容,可以用来说明T1表的职能。在Role name下面的Dependent默认是置成灰色,意即不可操作,这里我们就不管了。然后是Mandatory,这个是什么意思呢?这个是否选择决定了某个东西是否为空。是什么东西呢?指的是和本实体发生关系的对方实体的主键在本实体的外键字段是否为空。比如现在有种情况是T1中某个字段,如par1,该字段为外键,它将存储T2中的主键,则如果Mandatory被选中,则par1不为空,意即它必须存储某一个T2的值,而如果不选上,则表示该字段值可以为空。在现在的情况下T1T2是一对多的关系,我们知道在PDM中,出现的情况是T2中会生成一个外键,用来存储T1表的主键,而T1表不会有任何字段来存储T2的主键 ,所以这个Mandatory是否被选择上,不会对关系造成任何影响,所以这里我们就不用管它了。当然,我们从实际的描述中,可以这样来说明这个值的选取相关的情况,比如现在T1指的是部门,而T2指的是员工,当你选择了该值,则在后面的Cardinality中会变成1,n,即如果选择这个值,则表示一个部门至少有一个员工,而如果不选,则表示一个部门至少有0n个员工,就这个区别,因为为一对多,T1表中不会存储T2表中的主键,即使你选择了Cardinality,用于说明是部门至少含有1个员工,但是,T2表此时仍为空,没有任何员工,也不会出现问题的(这是因为一对多这个关系,导致T1表中不会有T2的任何相关信息造成的,当然在一对一的关系中,则不一样的,后面会说到)。

    现在再说说T2T1的内容里面的东西,其中的role name仍可以加入你所描述的T2的角色职责,比如“属于,包含于”等。在其下面,我们发现Dependent没有置灰了,是可以勾选的。我们先不管它,先趁热把Mandatory再说清楚点,此时由于我们已经知道T2表中会含有T1的主键的了,因为一对多的关系,则在生成的T2表时,会生成一个外键,用来单独存储T1的主键的,现在有个问题出现了,就是T2的存在是否依赖于T1,即说白一点就是一个员工是否一定要属于某一个部门?如果你的数据库系统中要求一定属于,那么你就把Mandatory选择上。反之,如果你认为新来的员工还没有分配好部门,可以暂时不让其属于某一个部门,到后面在人为的选择某一个部门,那么你就可以不用选择上Mandatory了。Cardinality会根据你是否选择Mandatory来决定其值是0,1还是1,1,意思很明确,就是是否T2一定属于T1,即一个员工是否一定属于一个部门。为这进一步确认Mandatory是否选中对PDM的实际表现造成的影响,可以通过CDM转化为PDM,查看其中的外键字段是否允许为空就可以明确了,如果你选择了Mandatory,则在PDMT2生成的外键中将不允许为空,即必须含有T1的某一主键,而如果不选择Mandatory,则在PDMT2生成的外键是可以允许为空的。

    好了,现在来说说Dependent的意思,如果其不选,则没有什么变化,如果其被选择中了,则会在PDM中对T2中生成的用于存储T1主键的那个外键(FK)将会成为T2的另外一个主键,这就是这个值的意思,如果你不需要T2中的外键同时成为主键,则不用选择该值。通常情况下,都不需要选择这个。

    2.一对一的关系说明

    在两个实体表中的关系中,如果一个表和另一个表是一对一的关系,这种一对一的关系有两种形式,以T1表和T2表为例。一种是T1中有个字段(外键)是T2表的主键,T2中有一个字段(外键)是T1表的主键,另一种情况是只有其中的一个表含有另一个表的主键,而另一个表不含有前一个表的主键。前面说的第一种情形是指两个实体互相感知,互相拥有对方的信息,另一种情况是指二者含有一定的依赖关系。某一个实体的存在依赖于另一个实体的存在。

    相对来说,在软件领域中,第二种情形更常见一些,完全平等的两个实体在现实中存在的意义不大,毕竟社会是一个充满着各种联系的实体,实体之间存在的着一定的依赖关系,就象孩子依赖于父母,员工依赖于企业,当然存在着两个互相感知的实体,这样带来的一个好处是在查询时非常迅速。下面说一下一对一关系的某些属性的改变带来的变化。

    T1T2实体建立好了关系之后,正如前面所言,默认情况下是个一对多的关系,我们这次就要改变这种关系了。在关系线的属性中,在Cardinalities属性页,我们将one-many修改为one-one,当我们选中one-one后,下面的Dominant role由原来的置灰不可操作状态变为可操作状态了。Dominant role的意思是占支配地位的角色,在其右边的下拉框中默认值为none,这里要求我们选择的是两个实体,谁占支配地位,谁占被支配地位。即谁支配谁。默认值中的none表示二者双方都不占支配地位,意即二者地位平等,则就是前面所述的第一种情况,即二者互相感知。这种情况下,在PDM中会发现T1表和T2表中都会生成一个外键,用于存储对方的主键。而下面的DependentMandatory和前面描述一对多的关系时表现是一样的。这里就不再赘述了,只是需要注意的一点是如果你的关系是二者互相平等的话,在选择Mandatory中,不要将T1T2都同时选择上,不然就会出现互斥现象,永远不成立。

    现在我重点说一下关于第二种情形,现在假设我们需要T2中的外键来存储T1的主键,那么这种情况下谁是支配地位的角色呢?在Dominant role中是选择T1->T2还是T2->T1呢?在->前面的是支配地位,后面的是被支配地位。想一下,为什么T2需要用一个外键来存储T1的主键呢?是因为T2需要T1的信息,需要T1来支持T2的存在,即T2依赖于T1,则说明T1应该是支配地位角色,那么在Dominant role项中,我们就需要选择T1->T2。明白了这个,就明白了为什么在一对多的关系里,这个Dominant role是置灰的呢?原因很简单,不需要我们指定这种支配角色,因为一对多的关系中,为一的那个必定是支配地位的角色,不需要我们改变。

    好了,关于实体之间的关系就结束了。如果你不是很确定关系的选项对后来的PDM造成的影响,你可以通过试验,通过简单的两个实体表,从CDM转化为PDM,实际看一下二者关系的表现,就明确了,这是我在实际的使用过程中,所用的方法。

    展开全文
  • 1.概念模型的表示方法     E-R图主要是由实体、属性和联系三个要素构成的。E-R图,使用了下面四种基本的图形符号。    2.确定系统实体、属性及联系  系统分析阶段建立数据字典和数据流程图->建立

     数据库建模:在设计数据库时,对现实世界进行分析、抽象、并从中找出内在联系,进而确定数据库的结构,这一过程就称为数据库建军模。它主权包括两部分内容:确定最基本的数据结构;对约束建模。

    1.概念模型的表示方法
      
      E-R图主要是由实体、属性和联系三个要素构成的。在E-R图中,使用了下面四种基本的图形符号。
      
      2.确定系统实体、属性及联系
      系统分析阶段建立数据字典和数据流程图->建立概念模型->逻辑模型->物理模型
      利用系统分析阶段建立的数据字典,并对照数据流程图对系统中的各个数据项进行分类、组织,确定系统中的实体、实体的属性、标识实体的码以及实体之间联系的类型。
      
      在数据字典中“数据项”是基本数据单位,一般可以作为实体的属性。“数据结构”、“数据存储”和“数据流”条目都可以作为实体,因为它们总是包含了若干的数据项。作为属性必须是不可再分的数据项,也就是说在属性中不能包含其他的属性。
      
      3.确定局部(分)E-R图
      
      根据上面的分析,可以画出部分实体-联系图。
      
      在这些实体中有下画线的属性可以作为实体的码,这几个实体之间存在着1:1、l:n和m:n几种联系。
      
      4.集成完整(总)E-R图
      
      各个局部(分)E-R图画好以后,应当将它们合并起来集成为完整(总)E-R图。在集成时应当注意如下几点:
      
      (1)消除不必要的冗余实体、属性和联系。
      
      (2)解决各分E-R图之间的冲突。
      
      (3)根据情况修改或重构E-R图。
      
      6.2.3逻辑结构设计
      
      逻辑结构设计的任务,就是把概念结构设计阶段建立的基本E-R图,按选定的管理系统软件支持的数据模型(层次、网状、关系),转换成相应的逻辑模型。这种转换要符合关系数据模型的原则。
      
      E-R图向关系模型的转换是要解决如何将实体和实体间的联系转换为关系,并确定这些关系的属性和码。这种转换一般按下面的原则进行:
      
      (1)一个实体转换为一个关系,实体的属性就是关系的属性,实体的码就是关系的码。
      
      (2)一个联系也转换为一个关系,联系的属性及联系所连接的实体的码都转换为关系的属性,但是关系的码会根据联系的类型变化,如果是:
      
      1:1联系,两端实体的码都成为关系的候选码。
      
      1:n联系,n端实体的码成为关系的码。
      
      m:n联系,两端实体码的组合成为关系的码。



    原文地址:http://blog.163.com/darwin_zhang/blog/static/1284887362009101683433176/

    展开全文
  • powerdesigner的概念模型中实体之间的关系是非常重要的,也决定了从概念模型转化到物理模型时的表现形式,所以有必须深究其中的相关设置。做数据库重要的就是表与表之间的关系,而这个关系是连接所有数据库系统...

    原文地址:http://blog.163.com/wcllu/blog/static/4624456920103813347480/

    在powerdesigner的概念模型中,实体之间的关系是非常重要的,也决定了从概念模型转化到物理模型时的表现形式,所以有必须深究其中的相关设置。做数据库重要的就是表与表之间的关系,而这个关系是连接所有数据库系统的纽带,所以即使我们不用PD,也应该重视表与表之间的关系。这也是关系型数据库的由来。

    PD中的表与表之间的关系有四种,分别是one-one(一对一),one-many(一对多),many-one(多对一),many-many(多对多)。在实际中使用得最多的只有前面两种,而多对一和一对多其实没有什么区别,只是二者关系的反向描述,所以其可以看成是一种类型。而多对多在实际的数据库设计中也是时有出现的,这种情况下,我们一般不直接处理多对多的关系,而是通过一种技巧,将多对多转化为多对一,和一对多的关系,这样可以简化数据库关系的复杂性。将多对多转化为多对一,再一对多意思是通过提供一个关联关系表,来使多对多的关系表与该关联关系表发生关系,而不让其直接发生多对多的关系,这样就可以简化这样的关系。前面文章中已经说明如何创建这种关联表了。这里也就不再说多对多的关系。后面只重点说明一对一,一对多的关系。

    在CDM中,实体之间的关系更符合现实情况一些,以一对多的关系来说,如果一个实体对应多个实体,通常含有“包含,拥有”等这样的意思在里面。比如一个部门拥有多个员工,一个企业拥有多个部门等。而如果多个实体对应一个实体,则通常含有“属于,包含于”等这样的意思。比如多个员工属于一个部门,多个部门包含于一个企业等。在PDM中就很具体了,且与实际的有些区别了,这主要是由于在软件的实现角度上的体现,比如一对多的关系,比如T1与T2的关系为T1一对多个T2,在PDM中,通常表现在T2中有一个外键,用来存储T1的主键,这样就叫一对多,而这样的表现与实际上具有一定的差别。当然这是没有什么问题的,因为PDM才是我们真正在软件实现时所采用的方式。我只是想说的是CDM中这种关系的描述,可能更和实际情况接近一些,也就更加容易明白一点。

    好了,下面分别说明一下一对多和一对一的关系详细说明:

    1.对于一对多的说明

    当两个实体需要进行一对多的关联时(比如T1与T2的关系为T1一对多个T2,T1和T2为两个实体),我们通过Relationship,从T1拉至T2时,二者关系就建立起来了。默认情况下就是个一对多的关系,即T1为1,T2为多。

    双击拉的关系线,则弹出二者关系描述的对话框,我们就可以在这个弹出的属性对话框里进行我们所需要的设置了。在弹出来的默认属性为General属性选项。我们可以在这个属性页里面修改关系名称以及对这个关系的描述等。点击Cardinalities属性页,在上面默认显示的就是一对多的关系,我们现在是描述一对多的关系,所以不修改它。在关系下面有个Dominant role,这个右边有个下拉框,不过是被置灰了,不可操作,这里先不管,后面在说一对一时再说说这里。

    在T1 to T2的内容里面,有个Role name,在其右边有个输入框,可以输入T1表的角色名字,这里就可以用前面提到的比如“拥有,包含”等这样的内容,可以用来说明T1表的职能。在Role name下面的Dependent默认是置成灰色,意即不可操作,这里我们就不管了。然后是Mandatory,这个是什么意思呢?这个是否选择决定了某个东西是否为空。是什么东西呢?指的是和本实体发生关系的对方实体的主键在本实体的外键字段是否为空。比如现在有种情况是T1中某个字段,如par1,该字段为外键,它将存储T2中的主键,则如果Mandatory被选中,则par1不为空,意即它必须存储某一个T2的值,而如果不选上,则表示该字段值可以为空。在现在的情况下T1与T2是一对多的关系,我们知道在PDM中,出现的情况是T2中会生成一个外键,用来存储T1表的主键,而T1表不会有任何字段来存储T2的主键 ,所以这个Mandatory是否被选择上,不会对关系造成任何影响,所以这里我们就不用管它了。当然,我们从实际的描述中,可以这样来说明这个值的选取相关的情况,比如现在T1指的是部门,而T2指的是员工,当你选择了该值,则在后面的Cardinality中会变成1,n,即如果选择这个值,则表示一个部门至少有一个员工,而如果不选,则表示一个部门至少有0至n个员工,就这个区别,因为为一对多,T1表中不会存储T2表中的主键,即使你选择了Cardinality,用于说明是部门至少含有1个员工,但是,T2表此时仍为空,没有任何员工,也不会出现问题的(这是因为一对多这个关系,导致T1表中不会有T2的任何相关信息造成的,当然在一对一的关系中,则不一样的,后面会说到)。

    现在再说说T2到T1的内容里面的东西,其中的role name仍可以加入你所描述的T2的角色职责,比如“属于,包含于”等。在其下面,我们发现Dependent没有置灰了,是可以勾选的。我们先不管它,先趁热把Mandatory再说清楚点,此时由于我们已经知道T2表中会含有T1的主键的了,因为一对多的关系,则在生成的T2表时,会生成一个外键,用来单独存储T1的主键的,现在有个问题出现了,就是T2的存在是否依赖于T1,即说白一点就是一个员工是否一定要属于某一个部门?如果你的数据库系统中要求一定属于,那么你就把Mandatory选择上。反之,如果你认为新来的员工还没有分配好部门,可以暂时不让其属于某一个部门,到后面在人为的选择某一个部门,那么你就可以不用选择上Mandatory了。Cardinality会根据你是否选择Mandatory来决定其值是0,1还是1,1,意思很明确,就是是否T2一定属于T1,即一个员工是否一定属于一个部门。为这进一步确认Mandatory是否选中对PDM的实际表现造成的影响,可以通过CDM转化为PDM,查看其中的外键字段是否允许为空就可以明确了,如果你选择了Mandatory,则在PDM中T2生成的外键中将不允许为空,即必须含有T1的某一主键,而如果不选择Mandatory,则在PDM中T2生成的外键是可以允许为空的。

    好了,现在来说说Dependent的意思,如果其不选,则没有什么变化,如果其被选择中了,则会在PDM中对T2中生成的用于存储T1主键的那个外键(FK)将会成为T2的另外一个主键,这就是这个值的意思,如果你不需要T2中的外键同时成为主键,则不用选择该值。通常情况下,都不需要选择这个。

    2.一对一的关系说明

    在两个实体表中的关系中,如果一个表和另一个表是一对一的关系,这种一对一的关系有两种形式,以T1表和T2表为例。一种是T1中有个字段(外键)是T2表的主键,T2中有一个字段(外键)是T1表的主键,另一种情况是只有其中的一个表含有另一个表的主键,而另一个表不含有前一个表的主键。前面说的第一种情形是指两个实体互相感知,互相拥有对方的信息,另一种情况是指二者含有一定的依赖关系。某一个实体的存在依赖于另一个实体的存在。

    相对来说,在软件领域中,第二种情形更常见一些,完全平等的两个实体在现实中存在的意义不大,毕竟社会是一个充满着各种联系的实体,实体之间存在的着一定的依赖关系,就象孩子依赖于父母,员工依赖于企业,当然存在着两个互相感知的实体,这样带来的一个好处是在查询时非常迅速。下面说一下一对一关系的某些属性的改变带来的变化。

    当T1和T2实体建立好了关系之后,正如前面所言,默认情况下是个一对多的关系,我们这次就要改变这种关系了。在关系线的属性中,在Cardinalities属性页,我们将one-many修改为one-one,当我们选中one-one后,下面的Dominant role由原来的置灰不可操作状态变为可操作状态了。Dominant role的意思是占支配地位的角色,在其右边的下拉框中默认值为none,这里要求我们选择的是两个实体,谁占支配地位,谁占被支配地位。即谁支配谁。默认值中的none表示二者双方都不占支配地位,意即二者地位平等,则就是前面所述的第一种情况,即二者互相感知。这种情况下,在PDM中会发现T1表和T2表中都会生成一个外键,用于存储对方的主键。而下面的Dependent和Mandatory和前面描述一对多的关系时表现是一样的。这里就不再赘述了,只是需要注意的一点是如果你的关系是二者互相平等的话,在选择Mandatory中,不要将T1和T2都同时选择上,不然就会出现互斥现象,永远不成立。

    现在我重点说一下关于第二种情形,现在假设我们需要T2中的外键来存储T1的主键,那么这种情况下谁是支配地位的角色呢?在Dominant role中是选择T1->T2还是T2->T1呢?在->前面的是支配地位,后面的是被支配地位。想一下,为什么T2需要用一个外键来存储T1的主键呢?是因为T2需要T1的信息,需要T1来支持T2的存在,即T2依赖于T1,则说明T1应该是支配地位角色,那么在Dominant role项中,我们就需要选择T1->T2。明白了这个,就明白了为什么在一对多的关系里,这个Dominant role是置灰的呢?原因很简单,不需要我们指定这种支配角色,因为一对多的关系中,为一的那个必定是支配地位的角色,不需要我们改变。

    好了,关于实体之间的关系就结束了。如果你不是很确定关系的选项对后来的PDM造成的影响,你可以通过试验,通过简单的两个实体表,从CDM转化为PDM,实际看一下二者关系的表现,就明确了,这是我在实际的使用过程中,所用的方法。


    摘自: qiuhong101

     

    http://blog.csdn.net/2000killer/archive/2009/04/24/4103685.aspx

    展开全文
  • 数据的四种常用的数据模型以及三实体之间的联系三个世界现实世界信息世界两个实体型间的联系数据模型层次模型 三个世界 现实世界 现实世界,客观存在的世界。 信息世界 概念:信息世界是现实人们头脑的反映,...
  • 概念模型概述

    2013-05-28 15:01:00
    的关联关系、相关的业务规则,在概念模型中不对实体的属性 建模。 概念模型的主要特征如下: 确定主要的概念实体,与现实中的信息进行映射。 确定各个概念实体之间的业务关系,描述现实中信息之间的关 系。 ...
  • 模型概念

    2010-08-03 11:17:00
    概念模型不包含设计的细节,仅定义核心业务实体、实体之间的关联关系、相关的业务规则,在概念模型中不对实体的属性建模。概念模型的主要特征如下: 1、 确定主要的概念实体 2、 确定实体之间的业务关系...
  • 最近进行UML学习过程,突然忘记了大学时关于数据库理论中概念模型、逻辑模型、物理模型之间的区别。随机复习上网并复习,并此记录一下,数据库建模是对现实世界进行分析、抽象、并从中找出内在联系,进而确定...
  • 关于数据库理论中概念模型、逻辑模型、物理模型之间的区别。随机复习上网并复习,并此记录一下,数据库建模是对现实世界进行分析、抽象、并从中找出内在联系,进而确定数据库的结构。  1、概念模型:就是从现实...
  • sql概念模型和逻辑模型

    千次阅读 2019-02-12 16:29:19
    概念模型的表示方法很多,目前比较常用的是实体联系模型,简称E-R模型。E-R模型主要用E-R图来表示。 实体间的联系有:一对一联系,一对多联系,多对多联系。 E-R模型用矩形框表示现实世界实体,用菱形框表示...
  • 内容:实体及实体之间的关系,在概念数据模型中,不包括实体的属性,也不用定义实体的主键,这是概念数据模型和逻辑数据模型的主要区别。 表示概念模型最常用的是“实体-关系”图,ER图主要是由实体、属性和...
  • PowerDesigner的概念模型中实体之间的关系是非常重要的,也决定了从概念模型转化到物理模型时的表现形式,所以有必须深究其中的相关设置。做数据库重要的就是表与表之间的关系,而这个关系是连接所有数据库系统...
  • ER模型(实体联系模型)的基本元素实体:是一个数据对象,ER模型中,实体用方框表示,方框内注明实体的名称联系:表示一个或多个实体之间的关联关系,联系用菱形框表示,并用线段将其与相关的实体联系起来属性:实体...
  • 此文是本人学习Oracle的时候,摘录和总结的一些Oracle基本理论知识...层次模型是指用树行结构表示实体及其之间的联系,树每一个节点代表一个记录类型,树状结构表示实体之间的联系。最著名最典型的层次数据库系统
  • 在数据仓库领域有一个概念叫conceptual data model,中文一般翻译为“概念数据模型”。 概念数据模型是最终用户对数据存储的看法,反映了最终...在概念数据模型中不包括实体的属性,也不用定义实体的主键。这是概...
  • Java内存模型概念

    2020-02-06 20:21:48
    命令式编程,线程之间的通信机制有两种:共享内存和消息传递。共享内存的并发模型里,线程之间共享程序的公共状态,通过写-读内存的公共状态进行隐式通信。消息传递的并发模型里,线程之间没有公共状态,...
  • ppt7~概念模型

    2020-04-28 18:20:36
    矩形框:表示实体矩形框写上实体的名字 椭圆形框:表示实体或联系的属性 菱形框:表示联系,记入联系名 连线:实体与属性之间;实体与联系之间;联系与属性之间用直线相连,(对于一对一联系,要两个实体连线...
  • 这个概念来源于J2EE的设计模式,原来的目的是为了EJB的分布式应用提供粗粒度的数据实体,以减少分布式调用的次数,从而提高分布式调用的性能和降低网络负载,但这里,我泛指用于展示层与服务层之间的数据传输对象...
  • 关系模型的基本术语定义:用二维表格来表示实体集,用关键码表示实体之间联系的数据模型称为关系模型有时也习惯称呼关系为表或表格,元组为行(Row),属性为列。关系属性个数称为“元数”,元组个数称为“基数”...
  • e-r概念模型

    2010-04-18 15:25:00
    确定系统实体、属性及联系 利用系统分析阶段建立的数据字典,并对照数据流程图对系统的各个数据项进行分类、组织,确定系统的实体、实体的属性、标识实体的码以及实体之间联系的类型。 数据字典“数据项”...
  • 关系模型的基本概念

    2013-08-18 23:19:52
    关系模型靠键来导航,表与表之间靠键关联起来,回到现实是事物之间的联系。   用图和表来表示思路,有几个好处,第一是简化了表达,一目了然;第二是提供了角度观察和思考问题的另一个角度。   这里的概念...
  • 又称为领域对象模型、概念模型、业务实体,它通常都具有目标对象的特征和行为,当多个领域模型结合一起时,就可以完成各种业务逻辑,其实也是对现实世界中对象之间关联关系的一种还原。 这里主要理解领域模型中的...
  • -在实体和持久层之间进行中介的对象。 像所有其他Hanami组件一样,它可以用作独立框架或完整的Hanami应用程序使用。 状态 联系 主页: : 邮件列表: : API文档: : 错误/问题: : 支持: : 聊天: ...
  • 在PowerDesigner中如何创建表 —物理模型 在上篇我们有说到,在PowerDesigner的概念模型中...其实在概念模型中创建表(实体)或者在物理模型中创建表的方法大致是一样的,不过还是有不同之处,比如在物理模型的表中...
  • 数据仓库领域有一个概念叫conceptual data model,中文一般翻译为“概念数据模型”。概念数据模型设计与逻辑数据模型设计、物理数据模型设计是数据库及数据仓库模型...概念数据模型的内容包括重要的实体及实体之间
  • 它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象(“业务类和对象”)之间...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 782
精华内容 312
关键字:

在概念模型中实体之间的