关系型数据库设计:实体关系模型详解

版权申诉
0 下载量 76 浏览量 更新于2024-07-01 收藏 331KB DOC 举报
"关系型数据库设计与分析" 关系型数据库设计是数据库系统开发中的关键步骤,它涉及到数据的组织和管理,确保数据的一致性、完整性和有效性。本资料主要探讨了实体关系模型(ER模型),这是进行概念设计的基础。 1. 实体关系模型(ER模型)是数据库设计的核心工具之一,用于描述现实世界的实体、属性和实体间的联系。实体是指可区分的实体,可以是人、物或抽象概念。属性则是描述实体特征的元素,如教师实体的属性包括教师编号、姓名、年龄等。域是属性可能取的所有值的集合,例如教师性别的域只有“男”和“女”。主码,或称关键字,是由一个或多个属性组成,能唯一标识实体的集合,如教师编号是教师实体的主码。 2. ER模型中,实体之间的联系分为三种类型:1:1(一对一)、1:n(一对多)和m:n(多对多)。1:1联系表示两个实体间一对一的对应关系;1:n联系是每个A实体对应B实体的一个或多个实例;m:n联系则表示A实体和B实体间存在多个匹配关系。 3. ER图是ER模型的图形化表示,通过矩形(实体)、椭圆(属性)和菱形(联系)来直观展示数据结构,使用无向边连接属性与实体,标记联系类型,使得设计更加清晰。 4. 在设计局部ER图时,通常会根据实际业务需求进行建模。例如,在教务管理系统中,学生和课程间是多对多的联系,因为一个学生可以选修多门课程,一门课程也可被多个学生选修。同样,教师和课程间也是多对多,一个教师可以教授多门课程,而一门课程可以由多个教师共同讲授。系与教师间是一对多联系,一个系有多个教师,而教师只属于一个系;系与学生间同样是一对多,一个系包含多个学生,每个学生隶属于一个系。 5. 综合成初步ER图的过程是将所有局部ER图整合,形成全局的、完整的数据库模型。这一步骤涉及识别所有实体、属性、联系,并确保模型满足所有的业务规则和约束。 设计关系型数据库时,ER模型和ER图的运用有助于捕捉业务需求,构建逻辑模型,进而转换为物理数据库结构。理解实体、属性、联系和它们之间的关系,是成功设计高效、可靠数据库的关键。在设计过程中,需要不断优化模型,消除冗余,确保数据的正常运作和高效查询。
2023-01-08 上传
目录 一 Codd的RDBMS12法则——RDBMS的起源 二 关系型数据库设计阶段 三 设计原则 四 命名规则   数据库设计,一个软件项目成功的基石。很多从业人员都认为,数据库设计其实不 那么重要。现实中的情景也相当雷同,开发人员的数量是数据库设计人员的数倍。多数 人使用数据库中的一部分,所以也会把数据库设计想的如此简单。其实不然,数据库设 计也是门学问。   从笔者的经历看来,笔者更赞成在项目早期由开发者进行数据库设计(后期调优需 要DBA)。根据笔者的项目经验,一个精通OOP和ORM的开发者,设计的数据库往往更为合 理,更能适应需求的变化,如果追其原因,笔者个人猜测是因为数据库的规范化,与OO 的部分思想雷同(如内聚)。而DBA,设计的数据库的优势是能将DBMS的能力发挥到极致 ,能够使用SQL和DBMS实现很多程序实现的逻辑,与开发者相比,DBA优化过的数据库更 为高效和稳定。如标题所示,本文旨在分享一名开发者的数据库设计经验,并不涉及复 杂的SQL语句或DBMS使用,因此也不会局限到某种DBMS产品上。真切地希望这篇文章对开 发者能有所帮助,也希望读者能帮助笔者查漏补缺。 一?Codd的RDBMS12法则——RDBMS的起源   Edgar Frank Codd(埃德加·弗兰克·科德)被誉为"关系数据库之父",并因为在数据库管理系统的理 论和实践方面的杰出贡献于1981年获图灵奖。在1985年,Codd 博士发布了12条规则,这些规则简明的定义出一个关系型数据库的理念,它们被作为所 有关系数据库系统的设计指导性方针。 1. 信息法则?关系数据库中的所有信息都用唯一的一种方式表示——表中的值。 2. 保证访问法则?依靠表名、主键值和列名的组合,保证能访问每个数据项。 3. 空值的系统化处理?支持空值(NULL),以系统化的方式处理空值,空值不依赖于数 据类型。 4. 基于关系模型的动态联机目录?数据库的描述应该是自描述的,在逻辑级别上和普通 数据采用同样的表示方式,即数据库必须含有描述该数据库结构的系统表或者数 据库描述信息应该包含在用户可以访问的表中。 5. 统一的数据子语言法则?一个关系数据库系统可以支持几种语言和多种终端使用方式 ,但必须至少有一种语言,它的语句能够一某种定义良好的语法表示为字符串, 并能全面地支持以下所有规则:数据定义、视图定义、数据操作、约束、授权以 及事务。(这种语言就是SQL) 6. 视图更新法则?所有理论上可以更新的视图也可以由系统更新。 7. 高级的插入、更新和删除操作?把一个基础关系或派生关系作为单个操作对象处理的 能力不仅适应于数据的检索,还适用于数据的插入、修改个删除,即在插入、修 改和删除操作中数据行被视作集合。 8. 数据的物理独立性?不管数据库的数据在存储表示或访问方式上怎么变化,应用程序 和终端活动都保持着逻辑上的不变性。 9. 数据的逻辑独立性?当对表做了理论上不会损害信息的改变时,应用程序和终端活动 都会保持逻辑上的不变性。 10. 数据完整性的独立性?专用于某个关系型数据库的完整性约束必须可以用关系数据库 子语言定义,而且可以存储在数据目录中,而非程序中。 11. 分布独立性?不管数据在物理是否分布式存储,或者任何时候改变分布策略,RDBM S的数据操纵子语言必须能使应用程序和终端活动保持逻辑上的不变性。 12. 非破坏性法则?如果一个关系数据库系统支持某种低级(一次处理单个记录)语言, 那么这个低级语言不能违反或绕过更高级语言(一次处理多个记录)规定的完整 性法则或约束,即用户不能以任何方式违反数据库的约束。 二?关系型数据库设计阶段 (一)规划阶段   规划阶段的主要工作是对数据库的必要性和可行性进行分析。确定是否需要使用数 据库,使用哪种类型的数据库,使用哪个数据库产品。 (二)概念阶段   概念阶段的主要工作是收集并分析需求。识别需求,主要是识别数据实体和业务规 则。对于一个系统来说,数据库的主要包括业务数据和非业务数据,而业务数据的定义 ,则依赖于在此阶段对用户需求的分析。需要尽量识别业务实体和业务规则,对系统的 整体有初步的认识,并理解数据的流动过程。理论上,该阶段将参考或产出多种文档, 比如"用例图","数据流图"以及其他一些项目文档。如果能够在该阶段产出这些成果, 无疑将会对后期进行莫大的帮助。当然,很多文档已超出数据库设计者的考虑范围。而 且,如果你并不精通该领域以及用户的业务,那么请放弃自己独立完成用户需求分析的 想法。用户并不是技术专家,而当你自身不能扮演"业务顾问"的角色时,请你选择与项 目组的相关人员合作,或者将其视为风险呈报给PM。再次强调,大多数情况,用户只是 行业从业者,而非职业技术人员,我们仅仅从用户那里收集需求,而非依赖于用户的