逻辑数据库设计有多种实现方式，包括：自顶至底，自底至顶以及混合方式。传统数据库设计是一个自底至顶的过程，从分析需求中的单个数据元素开始，把相关多个数据元素组合在一起转化为数据库中的表。这种方式较难应对复杂的大型数据库设计，这就需要结合自顶至底的设计方式。

　　使用ER模型进行概念数据建模方便了项目团队内部及与最终用户之间的交流与沟通。ER建模的高效性还体现在它是一种自顶至底的设计方法。一个数据库中的实体数量比数据元素少很多，因为大部分数据元素表示的是属性。辨别实体并关注实体之间的关系能大大减少需要分析的对象数量。

　　概念数据建模连接了两端，一端是需求分析，其能辅助捕获需求中的实体及之间的关系，便于人们的交流。另一端是关系型数据库，模型可以很容易的转化为范式化或接近范式化的SQL表。

　　概念数据建模步骤

　　让我们进一步仔细观察应在需求分析和概念设计阶段定义的基本数据元素和关系。一般需求分析与概念设计是同步完成的。

　　使用ER模型进行概念设计的步骤包括：

　　● 辨识实体与属性

　　● 识别泛化层次结构

　　● 定义关系

　　下面我们对这三个步骤一一进行讨论。

　　辨识实体与属性

　　实体和属性的概念及ER构图都很简单，但要在需求中区分实体和属性不是一件易事。例如：需求描述中有句话，“项目地址位于某个城市”。这句话中的城市是一个实体还是一个属性呢？又如：每一名员工有一份简历。这里的简历是一个实体还是一个属性呢？

　　辨别实体与属性可参考如下准则：

　　● 实体应包含描述性信息

　　● 多值属性应作为实体来处理

　　● 属性应附着在其直接描述的实体上

　　这些准则能引导开发人员得到符合范式的关系数据库设计。

　　如何理解上述的三条准则呢？

　　实体内容：实体应包含描述信息。如果一个数据元素有描述型信息，该数据元素应被识别为实体。如果一个数据元素只有一 个标识名，则其应被识别为属性。以前面的“城市”为例，如果对于“城市”有一些如所属国家、人口等描述信息，则“城市”应被识别为一个实体。如果需求中的 “城市”只表示一个城市名，则把“城市”作为属性附属与其他实体，如附属Project实体。这一准则的例外是当值的标识是可枚举的有限集时，应作为实体 来处理。例如把系统中有效的国家集合定义为实体。在现实世界中作为实体看待的数据元素 有：Employee，Task，Project，Department，Customer等。

　　多值属性：把多值属性作为实体。如果一个实例的某个描述符包含多个对应值，则即使该描述符没有自己的描述信息也应作为实体进行建模。例如：一个人会有许多爱好，如：看电影、打游戏、大篮球等。爱好对于一个人来说就是多值属性，则爱好应作为实体来看待。

　　属性依附：把属性附加在其最直接描述的实体上。例如：“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，特有描述符jobtitle，highest- degree等。