逻辑数据库设计有多种实现方式包括自顶至底自底至顶以及混合方式。传统数据库设计是一个自底至顶的过程从分析需求中的单个数据元素开始把相关多个数据元素组合在一起转化为数据库中的表。这种方式较难应对复杂的大型数据库设计这就需要结合自顶至底的设计方式。使用ER模型进行概念数据建模方便了项目团队内部及与最终用户之间的交流与沟通。ER建模的高效性还体现在它是一种自顶至底的设计方法。一个数据库中的实体数量比数据元素少很多因为大部分数据元素表示的是属性。辨别实体并关注实体之间的关系能大大减少需要分析的对象数量。概念数据建模连接了两端一端是需求分析其能辅助捕获需求中的实体及之间的关系便于人们的交流。另一端是关系型数据库模型可以很容易的转化为范式化或接近范式化的SQL表。概念数据建模步骤让我们进一步仔细观察应在需求分析和概念设计阶段定义的基本数据元素和关系。一般需求分析与概念设计是同步完成的。使用ER模型进行概念设计的步骤包括辨识实体与属性识别泛化层次结构定义关系下面我们对这三个步骤一一进行讨论。辨识实体与属性实体和属性的概念及ER构图都很简单但要在需求中区分实体和属性不是一件易事。例如需求描述中有句话“项目地址位于某个城市”。这句话中的城市是一个实体还是一个属性呢又如每一名员工有一份简历。这里的简历是一个实体还是一个属性呢辨别实体与属性可参考如下准则实体应包含描述性信息多值属性应作为实体来处理属性应附着在其直接描述的实体上这些准则能引导开发人员得到符合范式的关系数据库设计。如何理解上述的三条准则呢实体内容实体应包含描述信息。如果一个数据元素有描述型信息该数据元素应被识别为实体。如果一个数据元素只有一个标识名则其应被识别为属性。以前面的“城市”为例如果对于“城市”有一些如所属国家、人口等描述信息则“城市”应被识别为一个实体。如果需求中的“城市”只表示一个城市名则把“城市”作为属性附属与其他实体如附属Project实体。这一准则的例外是当值的标识是可枚举的有限集时应作为实体来处理。例如把系统中有效的国家集合定义为实体。在现实世界中作为实体看待的数据元素有EmployeeTaskProjectDepartmentCustomer等。多值属性把多值属性作为实体。如果一个实例的某个描述符包含多个对应值则即使该描述符没有自己的描述信息也应作为实体进行建模。例如一个人会有许多爱好如看电影、打游戏、大篮球等。爱好对于一个人来说就是多值属性则爱好应作为实体来看待。属性依附把属性附加在其最直接描述的实体上。例如“office-building-name”作为“Department”属性比作为“Employee”的属性合适。识别实体与属性并把属性附加到实体中是一个循环迭代的过程。识别泛化层次如果实体之间有泛化层次关系则把标识符和公共的描述符属性放在超类实体中把相同的标识符和特有的描述符放在子类实体中。举例来说在ER模型中有5个实体分别是Employee、Manager、Engineer、Technician、Secretary。其中Employee可以作为Manager、Engineer、Technician、Secretary的超类实体。我们可以把标识符empno公共描述符empname、address、date-of-birth放在超类实体中。子类实体Manager中放empno特有描述符jobtitle。Engineer实体中放empno特有描述符jobtitlehighest-degree等。定义关系在识别实体和属性之后我们可以处理代表实体之间联系的数据元素即关系。关系在需求描述中一般是一些动词如works-in、works-for、purchases、drives这些动词联系了不同的实体。对于任何关系需要明确以下几个方面。关系的度二元、三元等关系的连通数一对一、一对多等关系是强制的还是可选的关系本身有些什么属性。注关系的这些概念可参看数据库设计 Step by Step (3)这里不再赘述。冗余关系仔细分析冗余的关系。描述同一概念的两个或多个关系被认为是冗余的。当把ER模型转化为关系数据库中的表时冗余的关系可能造成非范式化的表。需要注意的是两个实体间允许两个或更多关系的存在只要这些关系具有不同的含义。在这种情况下这些关系不是冗余的。举例来说如下图1中Employee生活的City与该Employee所属的Professional-association的所在City可以不同两种含义故关系lives-in非冗余。图1 非冗余关系如下图2中的Employee工作的City与该Employee参与的Project的所在City在任何情况下都一致同种含义故关系works-in冗余。图2 传递性冗余关系三元关系非常小心的定义三元关系只有当使用多个二元关系也无法充分描述多个实体间的语义时我们才会定义三元关系。以Technician、Project、Notebook为例。例1如果 一个Technician只做一个Project一个Project只有一个Technician每个Project会被独立记录在一本Notebook中。图3 例1二元关系图例2如果一个Technician能同时做多个Project一个Project可以有多个Technician同时参与每个Project有一本Notebook多个做同一个Project的Technician共用一本Notebook。图4 例2二元关系图例3如果一个Technician能同时做多个Project一个Project可以有多个Technician同时参与一个Technician在一个Project中使用独立的一本Notebook。图5 例3三元关系图注三元关系的语义分析可参看数据库设计 Step by Step (4)这里不再赘述。我们假设要为一家工程项目公司设计一个数据库来跟踪所有的全职员工包括员工被分配的项目所拥有的技能所在的部门和事业部所属于的专业协会被分配的电脑。单个视图的ER建模通过需求收集与分析过程我们获得了数据库的3个视图。第一个视图是人力资源管理视图。每一个员工属于一个部门。事业部是公司的基本单元每个事业部包含多个部门。每一个部门和事业部都有一个经理我们需要跟踪每一个经理。这一视图的ER模型如图6所示。图6 人力资源关系视图第二个视图定义了每个员工的头衔如工程师、技术员、秘书、经理等。工程师一般属于某个专业协会并可能被分配一台工作站。秘书和经理会被分配台式电脑。公司会储备一些台式电脑和工作站以分配给新员工或当员工的电脑送修时进行出借。员工之间可能有夫妻关系这也需要在系统中进行跟踪以防止夫妻员工之间有直接领导关系。这一视图的ER模型如图7所示。图7 员工头衔及电脑分配视图第三个视图如图8所示包含员工工程师、技术员分配项目的信息。员工可以同时参与多个项目每一个项目可以在不同的地方城市设有总部。但一个员工在指定的地点只能做当地的一个项目。员工在不同的项目中可以选用不同的技能。图8 项目分配及技能