关系模式范式级别判断_架构设计:关系型数据库范式

设计关系数据库时,为了设计出合理的数据库表结构,需要遵从不同的规范要求,这些规范性要求被称为范式

     目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)

     各种范式呈递次规范,越高的范式数据库冗余越小。满足高层次范式的必定满足低层次范式,如一个数据库设计如果符合第二范式,一定也符合第一范式。

一、基本概念

     1、实体:现实世界中客观存在的并可以相互区分的对象或事物。如"公司"、"项目"、"员工"等。

     2、属性:实体所具有的某一特性。比如"公司名称"、"公司地址"都是实体"公司"的属性。

     3、:表中可以唯一确定一行数据的某个属性[或者属性组]。如[员工号]、[员工号绩效评定月份]。不同的表结构,对应的码不同。下文表(二)中,[员工号绩效评定月份]属性组就是码。

     4、主属性:包含在任何一个码中的属性称为主属性。下文表(二)中,员工号绩效评定月份就是主属性。

     5、非主属性:与主属性相反,没有在任何候选码中出现过,这个属性就是非主属性。下文表二中,员工姓名、部门、部门人数、绩效就是非主属性。

二、第一范式

     1、概述

     第一范式指的是符合第一范式的关系中的每个属性都不可再分

     2、实例分析

     下表(一)中,由于部门信息这个属性可以再分为部门和部门人数这两个属性,所以不符合第一范式。

员工号 员工姓名 部门   绩效评定月份  绩效 
部门 部门人数
10001 张三 开发部 30 201801 90
10001 张三 开发部 30 201802 85
10002 李四 集成部 30 201801 88
10002 李四 集成部 30 201802 87
10003 王五 综合部 5 201802 89
10004 马六 综合部 5 201802 85

表(一)

     将上表修改成

  • 3
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
商业银行信贷管理系统的数据库设计要点 [摘 要] 信贷管理系统的数据库设计是信贷管理系统建设的重点之一,直接关系到应用系统的架构 、性能、安全等。本文将从系统的业务功能、性能需求方面结合3年来信贷管理系统实施 中数据库的改进经验,对信贷管理系统数据库的设计要点做了较详细的分析,并提供了相 应的解决方案。 [关键词] 银行信贷管理系统;信贷;数据库;设计;性能;安全 一、引言 信贷管理系统是银行对其资产信贷业务进行全面的信息化管理系统,它包括客户信息 管理、评级授信管理、信贷审批管理、贷后监管与预警、五级风险分类管理、低质押物 管理、不良资产管理、业务分析等方面的管理。信贷管理系统的目的是控制和降低信贷 风险,降低管理成本,提供方便快捷的信贷服务,提供决策支持,其中控制和降低信贷风险 是其根本目的。 信贷管理系统是一个庞大而复杂的管理系统,对各个方面的要求十分严格,如系统性能 、安全性等。数据库是整个信贷管理系统的核心,它存放的是银行的所有客户资料数据和 贷款账户数据,其安全性十分重要;由于信贷管理系统的在线用户数量大,数据的存取频繁 、查询统计复杂多样,对数据库的存取性能要求很高。 下面就从业务功能方面谈谈构建信贷管理系统数据库的几个设计要点。本文所引用的 数据库模型是笔者全程参与设计和修改维护的一个信贷管理系统的后台数据库,经历了3 个省级商业银行的成功实施,历时3年,几经修改。 二、设计原则 (1) 规范性。在设计和操作维护数据库时,关键的步骤就是要确保数据正确地分布到数据库的 表中。使用正确的数据结构,不仅便于对数据库进行相应的存取操作,而且可以极大地简 化应用程序的其他内容,如查询、页面、报表、代码等。 (2) 正确性。数据库要能正确地描述信贷业务的信息、过程、关系,错误的信息描述将会带来 不可预知的问题,所以,在设计表时,要多与银行信贷业务人员、管理人员、高层领导沟通 ,从多个角度正确理解业务对象的信息内容、用途和关系,宁缺毋滥。 (3) 安全性。信贷管理系统的各个层面都要求有安全性保障,有应用程序层面的、操作系统层 面的、数据库层面的等。而对于绕过应用程序和操作系统直接进入数据库的操作,则更具 危险性,所以,数据库在设计和部署时要求有防篡改的手段或辅助的设计。 (4) 性能优先。数据库的设计要考虑数据存取的性能需求,例如,可以不按范式规范数据表,适 度的分表或分区设计等。 (5) 前瞻性。对一些可能需要扩充的功能模块或变化性比较大的功能模块,可以适当加入一些 前瞻性的设计或冗余设计。 三、设计要点 1. 整体规划 首先,在整体上收集和归纳信贷管理系统所涉及的业务对象的主要信息、用途、特点 和关系,然后,结合数据表的功能用途和存取特点进行分类,主要分类如下: (1) 组织人员权限(基础数据):主要是描述银行各组织机构、员工信息以及整个系统的访问控 制信息。 (2) 静态数据:静态数据包括两大类,即系统静态数据和业务静态数据,例如码表,以及业务类 型、贷款方式、担保方式、利率期限等业务参数。 (3) 客户基本信息:包括全部的企业客户和个人客户的档案信息,以及客户的联保小组、关联 企业、黑名单、白名单、财务报表、资产信息、不良记录等的信息。 (4) 评级授信:包括客户评级和授信的相关信息,主要有客户评级表、个人评分项目表、企业 定量评分表、企业定性评分表、客户授信记录表、按业务种类授信表、按贷款方式授信 表等。 (5) 模型数据:信贷管理系统中,用到的所有模型定义,主要有个人评级模型、企业定量评级模 型、企业定性评级模型、业务审批流程、风险分类模型、各类财务分析指标等。 (6) 业务数据:这是本系统的核心数据,包括科目、账号、借据、余额表、月末余额表、流水 表、月末欠息表、欠息表、利率表,此外还包括贷款合同、低质押物、担保人等表。 (7) 业务处理数据:业务处理数据是指业务处理过程中所产生的数据,主要是业务流程运行时 的过程数据,评级授信、信贷业务审批等业务流程的各个步骤及其相关的数据,待办事宜 等。 (8) 风险管理数据:主要包括五级分类、贷后监管、风险预警等方面的数据或信息。 (9) 日志:需要存储到数据库中的一些系统日志和业务日志数据。 2. 组织机构、人员与权限 组织机构、人员与权限系统被设计成一个独立的子系统,直接对应应用程序的机构人 员管理和权限管理认证模块,实际上在数据库中该部分数据也只是提供机构ID、人员ID的 外键关联或引用,见图1。 这一部分的应用程序和数据库设计成独立模块的一个主要考虑就是银行系统的应用整 合,如果整合,这一部分可直接用相应的模块替换或同步即可。 组织机构表的设计十分重要,除了正确描述机构间的从属关系外,最主要的是提高查询 性能,信贷管理系统中几乎所业的业务数据都与机构关联,而很多的
这个PDF文件是我花钱买来的,现在为了挣积分,拿出来与大家分享!! 本书深入浅出地介绍了目前世界上最受欢迎的数据库管理系统之一——SQL Server。全书共分三个部分:第一部分阐释了数据库的基本概念,讲解了数据库建模语言;第二部分展示了从概念建模到在SQL Server 2008上真正实现数据库的过程;第三部分深入探讨了SQL Server若干方面的技术细节,如数据保护、索引、并发访问等。通过将理论融入数据库实践,清晰地讲解了关系型数据库的设计原则,完整地展示了如何进行良好的关系型数据库设计,深入揭示了SQL Server 2008的技术细节。   本书浓缩了作者作为SQL Server数据库架构师多年来丰富的实践经验,适合各类数据库开发和管理人员学习参考 目录 第1章 数据库概念简介  1.1 数据库设计阶段   1.1.1 概念阶段   1.1.2 逻辑阶段   1.1.3 实现阶段   1.1.4 物理阶段  1.2 关系数据结构   1.2.1 数据库和模式   1.2.2 表、行和列   1.2.3 信息原则   1.2.4 域   1.2.5 元数据   1.2.6 键   1.2.7 未显式赋值的项(NULL)  1.3 实体之间的关系   1.3.1 二元关系   1.3.2 非二元关系  1.4 数据访问语言(SQL)  1.5 理解依赖性   1.5.1 函数依赖性   1.5.2 判定  1.6 总结 第2章 数据建模语言  2.1 数据建模介绍  2.2 实体  2.3 属性   2.3.1 主键   2.3.2 替代键   2.3.3 外键   2.3.4 域   2.3.5 命名  2.4 关系   2.4.1 识别性关系   2.4.2 非识别性关系   2.4.3 角色名字   2.4.4 关系基数   2.4.5 动词短语(关系名字)  2.5 描述信息  2.6 其他建模方法   2.6.1 信息工程   2.6.2 Chen ERD   2.6.3 Visio   2.6.4 Management Studio数据库关系图  2.7 最佳实践  2.8 总结 第3章 概念阶段数据建模  3.1 理解需求  3.2 文档化过程  3.3 需求收集   3.3.1 客户访谈   3.3.2 要回答的问题   3.3.3 现存的系统和原型   3.3.4 其他类型的文档  3.4 识别对象和过程   3.4.1 识别实体   3.4.2 实体间关系   3.4.3 识别属性和域  3.5 识别业务规则和业务过程   3.5.1 识别业务规则   3.5.2 识别基础业务过程  3.6 完成概念模型   3.6.1 识别明显的、额外的数据需求   3.6.2 和客户一起评审   3.6.3 重复以上步骤直到客户同意你的模型  3.7 最佳实践  3.8 总结 第4章 规范化过程  4.1 为什么要规范化   4.1.1 消灭重复数据   4.1.2 避免编写不必要的代码   4.1.3 给表瘦身   4.1.4 最大化聚集索引的使用   4.1.5 降低每张表中索引的数量  4.2 规范化应该走多远  4.3 规范化过程  4.4 实体和属性的形式:第一范式   4.4.1 所有属性必须是原子的   4.4.2 实体的所有实例必须包含相同数量的值   4.4.3 实体中出现的所有实体类型都必须不同   4.4.4 第一范式所避免的不规则编程   4.4.5 当前设计不符合第一范式的线索  4.5 属性间的关系   4.5.1 第二范式   4.5.2 第三范式   4.5.3 Boyce-Codd范式  4.6 实体中的多值依赖   4.6.1 第四范式   4.6.2 第五范式  4.7 非规范化  4.8 最佳实践  4.9 总结  4.10 额外的例子  4.11 本书迄今为止所讲述的故事 第5章 实现基础的表结构  5.1 评审逻辑设计  5.2 变换设计   5.2.1 选择名字   5.2.2 处理子类型   5.2.3 决定树的实现方式   5.2.4 选择键的实现方式   5.2.5 决定域的实现方式   5.2.6 设置模式   5.2.7 评审“最终的”实现模型  5.3 实现设计   5.3.1 创建基本表结构   5.3.2 添加唯一性约束   5.3.3 构建默认约束   5.3.4 添加关系(外键)   5.3.5 处理排序规则和排序   5.3.6 计算列   5.3.7 实现用户定义的数据类型   5.3.8 文档化你的数据库   5.3.9 处理依赖信息  5.4 最佳实践  5.5 总结 第6章 保护数据的完整性  6.1 最佳实

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值