数据库设计

数据库设计

  • 关系型数据库建议在E-R模型的基础上,我们需要根据产品经理的设计策划,抽取出来模型与关系,制定出表结构,这是项目开始的第一步
  • 在开发中有很多设计数据库的软件,常用的如power designer,db desinger等,这些软件可以直观的看到实体及实体间的关系
  • 设计数据库,可能是由专门的数据库设计人员完成,也可能是由开发组成员完成,一般是项目经理带领组员来完成
  • 现阶段不需要独立完成数据库设计,但是要注意积累一些这方面的经验

三范式

  • 经过研究和对使用中问题的总结,对于设计数据库提出了一些规范,这些规范被称为范式(Normal Form)
  • 目前有迹可寻的共有8种范式,一般需要遵守3范式即可
  • ◆ 第一范式(1NF):强调的是列的原子性,即列不能够再分成其他几列。

    考虑这样一个表:【联系人】(姓名,性别,电话) 如果在实际场景中,一个联系人有家庭电话和公司电话,那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列(电话)拆分,即:【联系人】(姓名,性别,家庭电话,公司电话)。1NF 很好辨别,但是 2NF 和 3NF 就容易搞混淆。

  • ◆ 第二范式(2NF):首先是 1NF,另外包含两部分内容,一是表必须有一个主键;二是没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。

    考虑一个订单明细表:【OrderDetail】(OrderID,ProductID,UnitPrice,Discount,Quantity,ProductName)。 因为我们知道在一个订单中可以订购多种产品,所以单单一个 OrderID 是不足以成为主键的,主键应该是(OrderID,ProductID)。显而易见 Discount(折扣),Quantity(数量)完全依赖(取决)于主键(OderID,ProductID),而 UnitPrice,ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。

    可以把【OrderDetail】表拆分为【OrderDetail】(OrderID,ProductID,Discount,Quantity)和【Product】(ProductID,UnitPrice,ProductName)来消除原订单表中UnitPrice,ProductName多次重复的情况。

  • ◆ 第三范式(3NF):首先是 2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。

    考虑一个订单表【Order】(OrderID,OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity)主键是(OrderID)。 其中 OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity 等非主键列都完全依赖于主键(OrderID),所以符合 2NF。不过问题是 CustomerName,CustomerAddr,CustomerCity 直接依赖的是 CustomerID(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合 3NF。 通过拆分【Order】为【Order】(OrderID,OrderDate,CustomerID)和【Customer】(CustomerID,CustomerName,CustomerAddr,CustomerCity)从而达到 3NF。 *第二范式(2NF)和第三范式(3NF)的概念很容易混淆,区分它们的关键点在于,2NF:非主键列是否完全依赖于主键,还是依赖于主键的一部分;3NF:非主键列是直接依赖于主键,还是直接依赖于非主键列。

E-R模型

  • E表示entry,实体,设计实体就像定义一个类一样,指定从哪些方面描述对象,一个实体转换为数据库中的一个表
  • R表示relationship,关系,关系描述两个实体之间的对应规则,关系的类型包括包括一对一、一对多、多对多
  • 关系也是一种数据,需要通过一个字段存储在表中
  • 实体A对实体B为1对1,则在表A或表B中创建一个字段,存储另一个表的主键值
  • 实体A对实体B为1对多:在表B中创建一个字段,存储表A的主键值
  • 实体A对实体B为多对多:新建一张表C,这个表只有两个字段,一个用于存储A的主键值,一个用于存储B的主键值
  • 想一想:举些例子,满足一对一、一对多、多对多的对应关系

逻辑删除

  • 对于重要数据,并不希望物理删除,一旦删除,数据无法找回
  • 删除方案:设置isDelete的列,类型为bit,表示逻辑删除,默认值为0
  • 对于非重要数据,可以进行物理删除
  • 数据的重要性,要根据实际开发决定

示例

  • 设计两张表:班级表、学生表
  • 班级表classes
    • id
    • name
    • isdelete
  • 学生表students
    • id
    • name
    • birthday
    • gender
    • clsid
    • isdelete
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数据库设计说明书 版本:V1.0 文 档 编 号 保 密 等 级 作 者 最后修改日期 审 核 人 最后审批日期 批 准 人 最后批准日期 修订记录 日期 版本 修订说明 修订人 目 录 1 引言 1 1.1 编写目的 1 1.2 系统名称及版本号 1 1.3 电子文档编写工具 1 1.4 定义说明与符号 1 1.5 参考资料 1 2 概述 1 3 命名 1 4 实体域设计 2 4.1 担保物 2 4.2 贷款申请 2 5 表模型设计 2 5.1 聚合表Package 2 5.2 xxx Package 2 5.2.1 CDBEC_PM_CONTROL_RECORD (表) 3 5.3 系统管理 3 5.3.1 运行日志 3 5.3.2 系统代码表 3 6 物理设计 3 6.1 数据视图 3 6.2 存储空间规划 3 6.3 冗余设计 3 6.4 索引设计 4 7 数据组织 4 7.1 数据分布方式 4 7.2 数据传输与通讯 4 7.3 历史数据管理 4 7.4 数据量估计 4 引言 编写目的 本文档是对xxx项目数据库模型的概要设计,是进行CDM模型设计基础。 系统名称及版本号 系统全称: 系统简称: 电子文档编写工具 【说明】工具名、版本号、操作系统平台。使用多种工具时,应分别说明。 Microsoft Office Word Professional Edition 2003 Microsoft Office Visio Professional Edition 2003 Sybase PowerDesigner® Version 9.5 定义说明与符号 【说明】包括对专用术语及缩略语的解释、所用到的图(物理数据模型图/功能层次图/逻辑框图/流程图等)中图符的表示与解释、屏幕界面中图标与按钮的表示与含义等。 参考资料 【说明】格式:作者,[版本号],资料来源,日期,[起止页号]。其中,《软件需求规格说明书》与《软件概要设计说明书》是必选的参考资料。 概述 模型域划分【说明】数据模型的整体划分原则,分多少个package,为什么如此划分: Package KM临时数据:用于接收KM平移过来的数据 Package 上报数据:按照上报系统的要求存储数据,供修改界面使用 命名 参照《开发银行数据平台命名规范》【说明】项目所引用的规范 项目空间CDBEC 【说明】项目所需建立的schema,如果有多个,要说明各自的用途 表前缀: 数据接收表 STA_【说明】依据规范罗列出本系统所需建立的表前缀 数据存储表 DT_ 系统管理表 SM_ 上报报文数据表 MS_ 上报过程管理表 PM_ 实体域设计 【说明】要确定模型设计的方式:星型、雪花,对于分析应用,可以按照主题域的方式进行实体域的设计 担保物 【说明】 1.从概要层次说明每类实体所反映的业务信息关系,说明实体域有多少实体。 2.通过PowerDesigner 做出实体间的主从关系,主从的数据关系及约束关系 3.在CDM模型中对字段进行解释 贷款申请 表模型设计 聚合表Package 【说明】说明聚合原因,聚合的依赖关系及层次。 xxx Package 【说明】每类package设计的原则 设计该系列表的目的是将数据复制到本地数据库后再进行计算,提高计算速度。如果未来使用数据ETL工具,虽然可以在抽取的过程中就完成大量的计算操作,但是考虑到这种工作方式需要相关系统都在线的情况下才能进行计算处理,对开发调试的环境要求较高,并且在上线运行后如果出现故障,还需要相关系统调整到位的情况下才能重新运行,因此在源到目标的数据移动过程中不进行复杂的数据运算,并且在本地保留接口数据表。 按照计算中需要从KM获取的数据表和数据项内容,进行设计,实现数据的简单平移。该部分模型需要参照目前有效发放系统、Symbols系统的表结构、命名、数据类型。 因为上报中要求对变更进行上报,当采集系统不能提供变更情况时,需要上报系统根据当天数据和前一次存储的数据进行比较之后才能知道发生了哪些业务变更。因此本系列的表需要对上报的数据保存本期和两期的数据。 CDBEC_PM_CONTROL_RECORD (表) 【说明】有特殊设计原因的表的用途,辨别此类表的方法:非业务数据存储表、实体域间的关联表、或设计规范中没有定义过的。注意不是简单解释字段的含义,而是要说明未来的系统如何使用这张表,以及表的变化更新情况 存储上报数据的概要汇总信息,每条上报数据在本表中有一条对应的存储记录。该表供查询界面中进行摘要信息显示,系统根据摘要记录再进行后续过程的处理。 在每天数据导入系统后,由系统向此表添加新的需要上报的数据。在xxx情况下该记录将被删除。…… 【说明】在CDM模型中对字段进行解释 系统管理 【说明】除了说明表的用途外,还要说明按照设计规范中的要求引用了哪些标准 运行日志 系统代码表 物理设计 数据视图 【说明】数据库视图、同义词、物化视图、DBLink的建设原因,并阐述是否存在性能问题 存储空间规划 【说明】 1.估算系统的初始数据量,增长量及周期,初始数据空间需求 2.是否建立独立的表空间,索引空间,临时表空间,使用的表空间名称 3.是否需要分区存储,哪些表进行分区存储,分区方案 冗余设计 【说明】 1.说明什么情况下进行了哪些数据项的冗余设计及原因 2.说明冗余设计后保证数据一致性的方案,如要求应用系统同步多处修改,还是系统提供变更服务 索引设计 【说明】 说明主键以外的索引原因 数据组织 数据分布方式 【说明】如集中式、分布式、混合式(集中+分布)。用图表予以描述。【说明】采用表格方式,应与数据量分布表对应。形如: 子系统名: 实体名 保存期限(天) 存放位置 CDBKM CDBFR 广域网服务器 数据传输与通讯 历史数据管理 【说明】 历史数据管理方式:备份磁带、备份表、删除 历史数据检索方式、数据恢复方式 历史数据操作方案 数据量估计 【说明】使用表格+文字的方式,对每个子系统进行估计。形如: 子系统名: 实体名 数据总量(KB) … … 本子系统数据总量= 占空系数= 预计数据量= 这里,预计数据量=本子系统数据总量×占空系数 其中,占空系数表示实际开销与理论开销之比值。其值可根据具体项目及运行环境而定,如可取1.5至2.5。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值