一步一步设计你的数据库之概念数据建模(1)
逻辑数据库设计有多种实现方式，包括：自顶至底，自底至顶以及混合方式。传统数据库设计是一个自底至顶的过程，从分析需求中的单个数据元素开始，把相关多个数据元素组合在一起转化为数据库中的表。这种方式较难应对复杂的大型数据库设计，这就需要结合自顶至底的设计方式。
使用ER模型进行概念数据建模方便了项目团队内部及与最终用户之间的交流与沟通。ER建模的高效性还体现在它是一种自顶至底的设计方法。一个数据库中的实体数量比数据元素少很多，因为大部分数据元素表示的是属性。辨别实体并关注实体之间的关系能大大减少需要分析的对象数量。
概念数据建模连接了两端，一端是需求分析，其能辅助捕获需求中的实体及之间的关系，便于人们的交流。另一端是关系型数据库，模型可以很容易的转化为范式化或接近范式化的SQL表。
概念数据建模步骤
让我们进一步仔细观察应在需求分析和概念设计阶段定义的基本数据元素和关系。一般需求分析与概念设计是同步完成的。
使用ER模型进行概念设计的步骤包括：
- 辨识实体与属性
- 识别泛化层次结构
- 定义关系
下面我们对这三个步骤一一进行讨论。
辨识实体与属性
实体和属性的概念及ER构图都很简单，但要在需求中区分实体和属性不是一件易事。例如：需求描述中有句话，“项目地址位于某个城市”。这句话中的城市是一个实体还是一个属性呢?又如：每一名员工有一份简历。这里的简历是一个实体还是一个属性呢?
辨别实体与属性可参考如下准则：
- 实体应包含描述性信息
- 多值属性应作为实体来处理
- 属性应附着在其直接描述的实体上
这些准则能引导开发人员得到符合范式的关系数据库设计。
如何理解上述的三条准则呢?
|
识别泛化层次
如果实体之间有泛化层次关系，则把标识符和公共的描述符(属性)放在超类实体中，把相同的标识符和特有的描述符放在子类实体中。举例来说，在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等。
定义关系
在识别实体和属性之后我们可以处理代表实体之间联系的数据元素即关系。关系在需求描述中一般是一些动词如：works-in、works-for、purchases、drives，这些动词联系了不同的实体。
对于任何关系，需要明确以下几个方面。
- 关系的度(二元、三元等);
- 关系的连通数(一对一、一对多等);
- 关系是强制的还是可选的;
- 关系本身有些什么属性。
注：关系的这些概念可参看一步一步设计你的数据库之看看基础ER模型，这里不再赘述。