数据库设计中ER模型设计问题范文

本站小编为你精心准备了数据库设计中ER模型设计问题参考范文，愿这些范文能点燃您思维的火花，激发您的写作灵感。欢迎深入阅读并收藏。

摘要：数据库设计中的概念结构设计阶段是一个复杂过程，学生在设计时往往不能很快的上手，或者设计出来的er图不合理或错误。本文针对学生在设计时易出现的问题和难点进行分析，通过一个设计好的ER图剖析其中存在的问题和错误。进而进一步论述了属性和实体的判断方法，属性间联系的判断和元数的确定方法，以及聚集的使用。通过论述为学生在数据库概念结构设计时提供可操作性强的方法和指导。

关键词：概念结构设计；ER模型；聚集

引言

在数据库原理课程教学中，长期以来存在一个难点，即数据库设计。数据库设计是指对于一个给定的应用环境，构造设计优化的数据库逻辑模型和物理结构，并据此建立数据及其应用系统，使之能够有效的存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。在学完数据库设计理论和数据操作后，学生对怎样根据一个具体的应用需求去设计一个优化的数据库仍然比较模糊。纠其原因主要有两个方面：一、在数据库的概念设计过程中，将需求转化为数据库的概念模式是一个复杂困难的过程。概念模式提供了一个应用环境中数据库用户的数据需求，设计者需反复检查以确保所有数据需求在此模式中都被满足，并且不相互冲突、没有冗余。这个过程是比较困难，它需要通过对需求进行综合、归纳和抽象。学生的这种综合、归纳和抽象能力较弱，不能很好的完成。二、概念模式定义了数据库中的实体、实体的属性、实体之间的联系以及实体上的限制。通常通过实体—联系图（ER图）来描述概念模式。现有很多相关教材说法不一、编写内容过于简陋，甚至错误，没有实操性，给学生在学习和思考上带来一定的误导。本文就概念模式设计时遇到的一些基本问题和解决方法进行探讨。

1从一个错误的ER图说起

ER图是描述概念模式的有力工具，它采用三个基本概念：实体集、联系集和属性。这里给出某一本科学生针对某企业考勤管理设计的ER图，如图1。该ER图中存在的问题在很多同学的设计中都存在。

1.1数据需求和行为需求分不清

数据库设计分为数据设计和行为设计两个部分，在图1中，设计者没有分清楚数据设计和行为设计中各自的活动内容。ER图表达的是应用环境中的数据需求，而不用于行为需求的表达。数据库概念模式的设计主要关注的是如何描述数据及其相互关系。在图1中“更新”，“查询”这些动词表达的是数据库用户的行为，而非实体集之间的相互关系，用户行为是在编写应用程序时考虑的内容。员工和考勤这两个实体集之间的关系应该是员工拥有考勤记录，“拥有”是员工实体集和考勤实体集之间的关系。

1.2实体确定有误

数据库概念模式设计的目标是产生反映应用环境信息需求的ER图，在图1中出现了“管理员”实体集，如果设计者是从系统安全的角度考虑的话，管理员属于数据库的用户，不是应用环境的信息，不应该出现在ER图中；如果设计者是为了实现管理者实体集和考勤实体集之间的关系，因为管理者实体集是员工实体集中的部分实体，那么这时可以将管理者实体集和员工实体集合并，而不用单独的把管理员实体集单独的拿出来，这样可以避免数据冗余。

1.3映射基数没有标注

映射基数是指明一个实体通过一个联系集能同时与多少个实体相关联。它依赖于该联系集所建模的对象在现实世界中的实际情况。如果联系集上的映射基数没有标注，那么概念模式在语义表达上信息不完整，对后续逻辑模型的设计将产生致命的影响。

1.4属性归属的判断

属性是实体集中每个成员所拥有的描述性性质。联系也可以有描述性属性。当一个属性是由参与的实体集联合确定而不是由单独的某个实体集确定时，该属性就必须放到联系集中。日期属性是用于记录考勤中某一类型发生时的时间，它是管理联系的描述性属性，表示管理者管理考勤信息的日期，由管理者和考勤同时决定。

1.5实体属性设计不合理

按照数据库设计理论中的“一事一地”的原则，ER模型中，实体不应该包含其它实体的属性，实体之间的关系通过“联系”来表达。考勤实体中包含了员工实体的主码属性，这是一个常见的错误，因为员工实体和考勤实体之间可以通过“拥有”联系表示两者之间的关系，而不是将这种关系隐含在属性中。与此相关的另一个常见的错误是将相关实体集的主码属性作为联系集的属性，因为在联系集的表示中已经隐含了这些主码属性。虽然在后续创建关系模式时这些属性会出现在联系集创建出的表中，但是，它们不应该出现在概念模式的联系集中。加班、出差、请假、迟到、旷到是考勤记录的几种类型，其中每种类型可以有多值，并且多种类型不可能同时存在，这样就会使数据库产生大量的空值，所以将其作为考勤的属性是不合理的。需要将其进行抽象，找出其共有的特征，因为加班、出差、请假、迟到、旷到这些属于考勤的类型，所以将加班、出差、请假、迟到、旷到这些抽象为考勤的“类型”属性，而加班、出差、请假、迟到、旷到这些作为“类型”属性的属性值。又因为加班、出差、请假、迟到、旷到等都涉及到时间段和具体的原因，所以在考勤实体上增加一个“内容”属性。

1.6一个可能的正确ER图

在概念模型设计时遵从“一事一地”的原则，即概念单一化。在ER图中创建的实体应该清晰、纯粹，尽可能与其他实体在意义上实现分离。完善的概念模式受到系统功能需求的影响，设计最终的概念模式应能满足系统的功能需求。经综合、归纳、抽象，按一定的功能需求将图1的ER图改为图2的ER图，这样就清晰的表达了现实中员工实体集、考勤实体集和员工考勤的联系集。

2ER图设计需要考虑的几个问题

ER图是一种语义模型，力图表达数据的意义。在设计时除了注意上述的知识点外，还需要注意以下几个方面的内容。

2.1用实体集还是属性

实体是现实世界中可以区别于其他对象的事物，实体通过一组属性来表示，属性是实体集中每个成员所拥有的描述性性质。实体和属性都通过名词来描述。什么作为属性，什么作为实体集，对这两个问题并不能简单的回答。名词到底是实体还是属性可以通过名词之间的限定来判断。如“职工”和“族别”都是名词，如果说成“职工的族别”在需求描述中是成立的，并且这时不存在有任何的名词被“族别”限定，那么就把“职工”作为实体，把“族别”作为“职工”的属性。又如“职工”和“考勤”都是名词，说成员工的考勤在需求描述中是成立的，但考勤中的请假，出差等值还有对应的具体内容，如请假的具体时间段、请假的原因等。这时考勤属性值不具有原子性，所以把考勤提升为实体对待。其中的请假、出差、加班等作为考勤的种类属性值，具体的时间段、原因等作为考勤的内容属性值。对上述员工考勤ER图中，如果将考勤处理成员工实体的属性，暗示对每个员工正好有一个考勤信息与之相关联。而将考勤作为一个实体，就允许每个员工可以有几个考勤信息与之相关联。这两者的主要差别是，将考勤作为一个实体来建模可以保存关于考勤的额外信息，如考勤的类型（请假、出差、加班等），考勤的具体内容，因此把考勤视为一个实体比把它视为一个属性的方式更具通用性；而且当这种通用性很重要的时候，这种定义方式就更为合适了。

2.2二元联系集与N元联系集

联系是指多个实体间的相互关联，一般通过动词来描述。哪些实体之间有联系，看作为实体的名词之间是否有动词存在，并且这个动词要体现在数据需求中。数据库中的联系通常都是二元的。如“职工”实体和“考勤”实体之间能说成“职工拥有考勤记录”在数据需求描述中是存在的，并且是为管理员工考勤信息功能提供数据支持的。那么认为“职工”和“考勤”之间的联系是存在的。又如“管理员”实体和“职工”实体，可以说成“管理员管理职工”，如果在数据需求描述中不存在这样的描述，那么“管理”这个动词就不作为联系，即不考虑管理员和职工之间管理的联系。对于非二元的联系可以用多个二元联系来表示，但如果这样做会额外的增加设计的复杂程度，以及对总得存储空间的需求。其实n元联系集可以更清晰地表达n个实体集之间的联系。如三元联系：“供应商给超市供应商品”，这个“供应”是三个实体集之间的联系，如果将其设计为供应商和超市之间的联系、超市和商品之间的联系、供应商和商品之间的联系这三个二元联系。假设供应商S1、S2给超市C1、C2供应商品P1、P2，从三个二元联中可以记录S1给超市C1、C2供货，S1供应P1、P2商品，但是无法记录S1给C1超市只供应商品P1不供应商品P2，S1给C2超市只供应商品P2不供应商品P1。而三元联系就表达的非常清晰。

2.3聚集

ER模型的一个局限性在于它不能表达联系间的联系。但有时这在应用设计时是必要的。这里用图书借阅这个实例来做以说明。图书和读者之间有借阅的联系，现在考虑读者借阅图书被罚款的请况，当图书归还时有超期、损坏、丢失等事情发生时对读者进行罚款。一种方法是将罚款作为借阅联系的一个多值属性，因为一些借阅是没有罚款的，这样会使得数据库中罚款项存在大量的空值，从逻辑结构和执行开销上都是不合理的。比如要查询某一罚款项是哪个读者借阅图书的罚款就比较困难。另一种方法将罚款作为一个实体，为了表示罚款联系，一种选择是创建读者、图书、罚款之间的一个三元联系，得到了图3的ER图（为了简单省略了实体集的属性）。但是，按照这种方法产生的ER图存在冗余信息，因为在罚款联系集中的每个读者信息和图书信息在借阅联系中也有。对上述情况建模的最好办法就是使用聚集。聚集是一种抽象，通过这种抽象，联系被当作高层实体来看待。这样，在这个例子中，将借阅联系看成一个高层实体集，并且可以像对待任何别的实体集那样对待这个高层实体集。这样，就可以在罚款和借阅之间创建一个二元联系来表示罚款是那一次借阅产生的。图4所示为用聚集的概念表示上述情况的ER图。

3总结

概念模式和具体应用环境的需求分不开，相同的应用环境下不同的需求可能对应不同的概念模式，所以概念模式一定是依据需求得到的，不能脱离需求、更改需求。概念模式设计是数据库设计过程中最易出错的部分，它涉及到人脑的抽象思维过程，需要大量的理论知识和实践经验。在设计时考虑的内容繁多复杂。对于数据库概念模型的设计，很多的教材和参考资料都有设计步骤，粗看之下简约明了，但可操作性甚小。学生掌握了这些流程后仍不能正确快速的设计出概念模式。笔者结合多年的教学经验，在前人设计理论的基础上进行了总结分析，通过一个典型的错误实例，分析了学生在设计概念模型时容易出现错误的地方，通过分析使学生清楚的理解数据库概念模式设计时应注意的知识点。为学生设计概念模式提供了有力的理论依据和设计方法。

参考文献：

[2]王珊，萨师煊.数据库系统概论（第5版）[M].北京:高等教育出版社，2014:15-16.

[3]赵良辉.数据库课程中ER模型设计的反例教学[J].教育技术，2012,8:8-10.

[4]徐广定，潘锦平.实体联系模型-用作数据的统一的观点[J]计算机工程与应用，1983,12:22-37.

作者：牛荣 陈纪龙 杜义君 单位：塔里木大学信息工程学院