E-R模型属于数据库设计的范畴，是数据库设计中非常重要的一部分，要想清楚地知道E-R模型在设计中的额地位，还是要从设计过程看起。

一.设计过程概览

    1.获取用户需求阶段：生成功能需求规格说明（specification of funcation requirement）。

    2.概念设计阶段（conceptual -design phase）：概念定义了数据库中表示的实体、实体的属性、实体之

       间的联系和实体上的限制。是对一个企业功能和业务的详细描述。最后创建E-R图对模式进行图形化描述。

       是逻辑设计阶段生成关系（表）的基础。

    3.逻辑设计阶段（logical-design phase）：将高层的概念设计映射为加将被使用的数据库系统的实现数据

      模型（通常是关系数据模型）。

    4.物理设计阶段（physical-design phase）：定义数据库的物理特征，包括文件组织格式和内部存储结构.

 

二.设计中主要需要解决或避免的两个矛盾

    1.冗余（redundancy），很多数据库初学者对冗余一词不是很敏感，对这个词的理解也只是局限于字面

       意思。感觉不就是多存了点没用的数据吗，这有什么，能占多少空间？其实之所以把它列为主要的陷阱，

       更深层次的原因是冗余可能导致数据的不一致，相信说到这里你就能感觉到它的致命性了。

       举个例子，

customer_id	loan_number	amunt
1	L110	1000
2	L110	1000
3	L110	1000

       看出来这个表中的信息绝对是冗余的，现在问题来了，如果按照loan_number更新amount属性，没

       问题；但是如果按'where customer_id=*'进行更新，数据就不一致了。这在数据库系统中是绝对不允许

       出现的。

    2.不完整（incompleteness）：不合理的设计会使数据库使用者受到很大限制（工作时）甚至无法在规定

       范围工作。比如：一个属性过于复杂的关系可能会导致当有些属性目前不存在（以后会有）时就不得不用

       NULL代替，而处理NULL时又很头疼有时甚至无法解决。

       要解决这些问题需要引入图形化描述语言才能更有效的解决，E-R图应运而生。

 

三.构成元素

    1.实体（entity）

      ①强实体集(trong entity)

      ②弱实体集(weak entity) 

    2.联系(relationship)

    3.属性(attribute)

      ①简单/复合属性(simple/composite attribute)

      ②单值/多值属性(single-valued/multi-values)

      ③描述性属性(descriptive attribute)

       ④派生属性(derived attribute)

 

四.实体与联系之间的关系——约束

    1.映射基数

    2.码：这一部分有必要特殊强调一下！！

       不论你想不想深入研究数据库设计，你都要对码的概念熟悉和敏感。

       在数据库设计中，码扮演者重要的角色。在E-R模式设计中，码只是崭露头角；在之后的逻辑设计阶段码

       才扮演着重中之重的角色，它是调整并生成关系模式的key。。名副其实，到那时你就要对超码，候选码的

       概念理解绝对透彻才行。

      ①实体集码的确定

      ②联系集码的确定：取决于两端实体集的映射基数

                               a)多对多取（主码）并

                               b)一对一取（任）一

                               c)多对一取多

    3.参与约束

      实体集参与到关系的方式，分为：全部参与、部分参与；

 

五.数据库设计时需要面临的决策问题

    这些都没有固定的规则或明确的定义，只能凭借对实体或属性的分析和对企业要求的理解再加上点经验。这里我没什么经验，只能稍微介绍一点，况且这种介绍只能通过例子来说明。

    1.用实体集还是用属性

      假设有一个employee实体集，具有employee_id,employee_name,employee_phone.

      我们在employee_phone上讨论这个问题：

      如果企业规定一个人只存储一个电话号码，这个问题就不是问题。但是试想，如果公司允许有一个人有多个

      号码呢？甚至是要求有多个号码呢？

      这样的话就有问题了。用实体还是用属性？

      首先如果用属性的话，这个属性就是个多值属性。在设计中一般把多值属性分解成多个单值属性，这样的

      话那些提供不满公司要求号码数量的员工的号码只能用NILL来代替，这是需要衡量的。

      如果公司要求还要说明号码的地点或类型（住宅or手机or办公室），那问题就更大了，这个属性变成了复

     合属性。设计中一般把复合属性单成一个实体。此时，既解决了NULL问题，又解决了location问题。

    2.用实体集还是用联系集

      这个问题是产生冗余和不一致的主要问题。所以在分析时冗余是主要考虑因素。

    3.用二元联系集还是n元联系集

       暂时我无解···

    4.联系属性的布局（归属问题）

      ① 一对一联系集的属性可以放置到任何一方实体中；

      ②一对多联系集的属性可以放置到“多”的那一方实体中；

      ③问题在于多对多怎么办——让我们看一个客户访问账户时间的例子，下面是前提：

         一个客户可以有多个账户，一个账户可以被多个用户拥有（对于访问账户来说就是多对多）。如贷款

         账户；

         如果将访问时间放到账户实体中，我们可以知道那个账户被访问，但不知道是被谁访问；

         如果将访问时间放到用户实体中，我们可以知道那个用户访问了，但不知道访问了哪个账户；

         如果把这个访问时间作为访问关系的一个属性，这个问题就可以解决，可以知道谁访问了哪个账户。

 

 

Be continued···