关系数据库设计:构建最优模式

4星 · 超过85%的资源 需积分: 15 27 下载量 80 浏览量 更新于2024-08-01 收藏 112KB PPT 举报
"关系数据库设计是构建最优数据库模式的过程,以满足用户的数据存储、维护和检索需求。设计通常基于通用的数据库管理系统(DBMS)进行,涉及数据库应用系统(DBAS)的创建。数据库在信息系统中起着核心作用,支持数据处理系统(EDP)、信息管理系统(MIS)和决策支持系统(DSS)。设计特点包括硬件和软件的结合,以及结构设计(定义信息内容)和行为设计(确定系统功能)。设计过程包括需求分析、概念结构设计、逻辑结构设计、物理设计、应用程序设计等步骤,最后是数据库的实施、运行和维护。" 关系数据库设计是信息系统开发的关键环节,旨在为特定应用环境构建最佳的数据库结构。在这个过程中,设计者需要考虑如何有效地存储和管理数据,同时满足用户的多种需求。数据库设计通常借助于现有的数据库管理系统来实现,这些系统为数据管理提供了基础框架。 数据库应用系统是围绕数据库构建的一系列系统,它们共同构成了一个集成的数据库工程,包括结构设计(定义数据库模式)和行为设计(设计事务处理等应用程序)。这两个方面相互依赖,共同决定了系统的功能和性能。图5.1展示了这种结构设计和行为设计的关系,从现实世界的分析到最终的数据库运行和维护,每个阶段都是紧密相连的。 数据库设计的过程可以分为多个阶段。首先,需求分析阶段收集并理解用户的需求。接下来,概念结构设计阶段创建概念模型,逻辑结构设计阶段则将这些概念转化为具体的数据库模式。物理结构设计关注数据在存储设备上的实际布局,以优化性能。然后,事务设计和应用程序设计确保系统能执行必要的操作。最后,数据库的实施、运行和维护确保其持续有效并适应变化的需求。 信息系统是用于提供信息和支持决策的系统,根据功能不同,可分为数据处理系统、信息管理系统和决策支持系统。数据库作为这些系统的核心,负责数据的组织、存储和检索,确保信息的及时、准确获取。 总结来说,关系数据库设计是一项涉及硬件、软件、需求分析、模式设计和应用程序开发的复杂任务。这一过程不仅关注数据的结构,也关注数据的处理,确保数据库应用系统能够高效、稳定地运行,并满足用户的各种需求。
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。再次强调,大多数情况,用户只是 行业从业者,而非职业技术人员,我们仅仅从用户那里收集需求,而非依赖于用户的