11-个重要的数据库设计规则
Oracle数据库设计规范建议
Oracle数据库1 数据对象的命名规范1.1 通用规范1.1.1 使用英文:要用简单明了的英文单词,不要用拼音,特别是拼音缩写。
主要目的很明确,让人容易明白这个对象是做什么用的;1.1.2 一律大写,特别是表名:有些数据库,表的命名乃至其他数据对象的命名是大小写敏感的,为了避免不必要的麻烦,并且尊重通常的习惯,最好一律用大写;1.2 数据库对象命名规范1.2.1 表的命名1.2.1.1 表名的前缀:前缀_表名_T。
为表的名称增加一个或者多个前缀,前缀名不要太长,可以用缩写,最好用下划线与后面的单词分开;其目的有这样几个:1.2.1.1.1 为了不与其他项目或者其他系统、子系统的表重名;1.2.1.1.2 表示某种从属关系,比如表明是属于某个子系统、某个模块或者某个项目等等。
表示这种从属关系的一个主要目的是,从表名能够大概知道如何去找相关的人员。
比如以子系统为前缀的,当看到这个表的时候,就知道有问题可以去找该子系统的开发和使用人员;1.2.2 视图命名:相关表名_V(或者根据需要另取名字);1.2.3 程序包命名:程序包名_PKG(用英文表达程序包意义);1.2.4 存储过程命名:存储过程名_PRO(用英文表达存储过程意义);1.2.5 函数命名:函数名称_FUN(用英文表达函数作用);1.2.6 触发器命名:触发器名称_TRI(用英文表达触发器作用);1.2.7 索引命名:表名_字段名_IDX(如果存在多字段索引,取每字段前三个字符加下划线组合,如在 custom, cutting, curtail 上建立联合索引,命名为表名_cus_cut_cur_IDX,如果前三个截取字符相同,就从字段名称中不同的字符开始取三个字符加下划线组合,如在 custid, custom,custname上建立联合索引,就命名为表_tid_tom_tna_IDX;1.2.8 唯一索引命名:表名_字段名_UNI(如果存在多字段唯一索引,取每字段前三个字符加下划线组合,如在 custom, cutting, curtail上建立唯一索引,命名为表名_ cus_cut_cur_UNI,如果前三个截取字符相同,就从字段名称中不同的字符开始取三个字符加下划线组合,如:在 custid, custom,custname上建立唯一索引,命名:表_tid_tom_tna_UNI;1.2.9 主键命名:表名_字段名_PK(如果存在多字段主键,取每字段前三个字符加下划线组合,如在 custom, cutting, curtail上建立主键,命名为表名_cus_cut_cur_PK,如果前三个截取字符相同,就从字段名称中不同的字符开始取三个字符加下划线组合,如在 custid, custom,custname上建立主键,命名:表_tid_tom_tna_PK;1.2.10 外键命名:表名_主表名_字段名_FK;1.2.11 Sequence命名:表名_列名_SEQ(或者根据需要另取名字);1.2.12 Synonym命名:与对应的数据库对象同名;1.2.12 JAVA命名:遵守公司相应的JAVA命名规范;2 SQL的设计和使用2.1 Sql 书写规范2.1.1 尽量不要写复杂的SQL:过于复杂的S QL可以用存储过程或函数来代替,效率更高;甚至如果能保证不造成瓶颈的话,把条SQL拆成多条也是可以的。
mysql 数据库设计命名规则
mysql 数据库设计命名规则
在MySQL数据库设计中,命名规则是非常重要的,它有助于提
高数据库的可读性和可维护性。
以下是一些常见的MySQL数据库设
计命名规则:
1. 表名命名规则:
使用有意义且描述性强的表名,避免使用简单的单词或缩写。
表名应该使用复数形式,以便清楚地表示其包含多个实例。
使用下划线或驼峰命名法来提高表名的可读性。
2. 字段名命名规则:
字段名应该简洁明了,能够清晰地描述其所代表的数据。
避免使用保留字作为字段名,以免引起冲突。
采用下划线或驼峰命名法来提高字段名的可读性。
3. 约束名命名规则:
约束名应该清晰表达其所起的作用,例如主键约束、外键约
束等。
约束名应该与表名和字段名保持一致,以便于理解和维护。
4. 索引名命名规则:
索引名应该清晰描述其所涉及的字段以及索引类型,例如
idx_字段名等。
避免使用过于复杂或含糊的索引名,以免混淆。
5. 视图和存储过程命名规则:
视图和存储过程的命名应该反映其所包含的数据或逻辑,便
于理解和识别。
总的来说,MySQL数据库设计的命名规则应该遵循清晰、简洁、有意义的原则,以便于他人阅读和理解,提高数据库的可维护性和
可扩展性。
同时,也要注意避免使用特殊字符和空格,以免引起不必要的麻烦。
希望以上信息能够对你有所帮助。
11 数据库设计说明-GJB438C模板
编号:版本:状态:密级:分发号:XXX数据库设计说明编制/日期:审核/日期:标审/日期:会签/日期:批准/日期:XX科技有限公司XXXX年X月文档修订记录目录1范围 (1)1.1标识 (1)1.2数据库概述 (1)1.3文档概述 (1)2引用文档 (1)3数据库级设计决策 (2)4数据库详细设计 (3)4.X(数据库设计级别的名称) (3)5用于数据库访问或操纵的软件单元详细设计 (5)5.X(软件单元的唯一标识符,或者一组软件单元的标志符) (6)6需求可追踪性 (8)7注释 (9)1范围1.1标识【注释:本条应描述本文档所适用的系统和软件(数据库)的完整标识,(若适用)包括其标识号、名称、缩略名、版本号和发布号。
】1.2数据库概述【注释:本条应简要描述本文档所适用数据库的用途。
它还应描述数据库的一般特性;概述其开发、使用和维护的历史;标识项目的投资方、需方、用户、开发方和保障机构等;标识当前和计划的运行现场;列出其他有关文档。
】1.3文档概述【注释:本条应概述本文档的用途和内容,并描述与它的使用有关的安全保密方面的要求。
】2引用文档【注释:本章应列出引用文档的编号、标题、编写单位、修订版及日期,还应标识不能通过正常渠道得到的文档的来源。
】3数据库级设计决策【注释:本章应根据需要分条给出数据库级设计决策,即数据库的行为设计决策(忽略其内部实现,从用户角度出发描述数据库将怎样运转以满足需求)以及其他影响数据库进一步设计的决策,并给出决策理由。
如果决策在系统需求或软件需求中均是明确的,本章应如实陈述。
针对关键性需求(例如对安全性或保密性需求)的设计决策,应在专门的章条中加以叙述。
如果设计决策依赖于系统状态或方式,应指明这种依赖关系。
如果部分或全部设计决策在用户的或商用的数据库管理系统(DBMS)中进行了描述,本章可以直接引用。
本章应给出或引用需要了解的设计约定。
数据库级设计决策的例子如下:a) 关于数据库将接收的查询或其他输入以及它将产生的输出(显示、报表、消息、响应等)的设计决策,包括与其他系统、硬件、软件及用户的接口(本文档的5.X.d条指出这项说明应考虑的主题)。
数据库的设计原则
更重要的是督促读者学会“列变行”,这样就防止了将子表中的字段拉入到主表中去,
在主表中留下许多空余的字段。
所谓“列变行”,就是将主表中的一部分内容拉出去,另外单独建一个子表。
这个方法很简单,有的人就是不习惯、不采纳、不执行。
11. 中间表、报表和临时表
中间表是存放统计数据的表,它是为数据仓库、输出报表或查询结果而设计的,
有时它没有主键与外键(数据仓库除外)。
临时表是程序员个人设计的,存放由程序员自己用程序自动维护。
“键,到处都是键,除了键之外,什么也没有”,
这就是他的数据库设计经验之谈,也反映了他对信息系统核心(数据模型)的高度抽象思想。
因为:主键是实体的高度抽象,主键与外键的配对,表示实体之间的连接。
3. 基本表的性质
基本表与中间表、临时表不同,因为它具有如下四个特性:
一本图书在不同时间可以被多个读者借阅,一个读者又可以借多本图书。
为此,要在二者之间增加第三个实体,该实体取名为“借还书”,
它的属性为:借还时间、借还标志(0表示借书,1表示还书),
另外,它还应该有两个外键(“图书”的主键,“读者”的主键),
因为“金额”可以由“单价”乘以“数量”得到,说明“金额”是冗余字段。
但是,增加“金额”这个冗余字段,可以提高查询统计的速度,这就是以空间换时间的作法。
在Rose 2002中,规定列有两种类型:数据列和计算列。
“金额”这样的列被称为“计算列”,而“单价”和“数量”这样的列被称为“数据列”。
(1) 在数据库物理设计时,降低范式,增加冗余, 少用触发器, 多用存储过程。
(2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条),复杂计算要先在数据库外面,
数据库设计规范
数据库设计规范
数据库是计算机上最重要的存储组织和管理工具,它用于保存和管理数据,是所有大型数据操作的基础。
因此,数据库设计规范尤为重要,有助于组织有效地管理其信息资源。
首先,在数据库设计规范中应给出一个有效的逻辑结构来定义数据库,其应包括:表、字段、关系、视图、功能、安全性等。
其次,要求符合数据完整性的原则,也就是将要求数据库中的每个字段和表都遵循一定的规则和流程,以保证数据的完整性。
此外,在数据库设计规范中还应考虑易用性,要求用户在访问和更新数据时要轻松实现,同时保证数据库的安全性和可靠性。
另外,在数据库设计规范中,还要考虑实施和维护方面的因素。
在实施阶段,必须设计可信息技术部门使用的管理工具,使其能够有效地监控和管理数据库的运行情况;同时,在维护阶段,应定期对数据库进行检查,如备份、复制等,以便进行数据保护和维护。
综上所述,数据库设计规范是一个系统而完整的过程,包括确定表结构、定义索引、实施安全性、实现易用性等。
以上所有操作都是大型数据库中组织和管理数据的基本要求,必须以一套合理的数据库设计规范来实施,以保证数据库的完整性,安全性和可靠性。
为了保证数据库的正常工作,提高数据库的管理效率,应建立一套完善的数据库设计规范,将系统概念转换为实际的设计过程,让用户更加方便的使用数据库。
另外,还应不断适应新的数据库技术,为企业提供更具备未来竞争力的数据库设计方案。
数据库设计规范与命名规则
数据库设计规范、技巧与命名规范一、数据库设计过程数据库技术是信息资源管理最有效的手段。
数据库设计是指:对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求。
数据库设计的各阶段:A、需求分析阶段:综合各个用户的应用需求(现实世界的需求)。
B、在概念设计阶段:形成独立于机器和各DBMS产品的概念模式(信息世界模型),用E-R图来描述。
C、在逻辑设计阶段:将E-R图转换成具体的数据库产品支持的数据模型,如关系模型,形成数据库逻辑模式。
然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。
D、在物理设计阶段:根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。
1. 需求分析阶段需求收集和分析,结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。
需求分析的重点:调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。
需求分析的方法:调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。
常用的调查方法有:跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
自顶向下的结构化分析方法(Structured Analysis,简称SA方法)从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图和数据字典描述。
数据流图表达了数据和处理过程的关系。
系统中的数据则借助数据字典(Data Dictionary,简称DD)来描述。
2. 概念结构设计阶段通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,可以用E-R图表示。
概念模型用于信息世界的建模。
概念模型不依赖于某一个DBMS支持的数据模型。
概念模型可以转换为计算机上某一DBMS 支持的特定数据模型。
数据库设计规范标准
关系型数据库设计规目录文档类别使用对象21. 概述31.1 简介31.2 术语定义31.3 参考资料31.4 版本更新记录32.数据库设计的目标43. 数据库的特征43.1完整性约束43.1.1not null约束53.1.2缺省值53.1.3 unique约束53.1.4 primary key约束53.1.5 参照完整性约束63.1.6 check约束63.2 存储过程63.3 触发器73.4 事务处理73.4.3 事务与一致性73.4.4 事务和恢复83.5 并发处理83.5.3 死锁93.5.4 读一致性93.6 序号生成器93.7 视图93.7.3 安全性103.7.4 逻辑数据独立性104. 调整数据库设计以提高系统性能104.1 建立有用的性能标准104.2 数据库的规化114.3 通过非规化设计提高数据库的效率114.3.3 非规化的原因114.3.4 非规化技术114.3.5 进行非规化处理时的注意事项124.4 表的大小124.4.3 表是否过小124.4.4 表是否过大134.4.5 如何减小表的尺寸134.5 记录的大小134.5.3 列有最佳的位置吗134.5.4 存在最佳的记录大小吗134.5.5 记录是否过小134.5.6 记录是否过大134.5.7 如何减小记录134.5.8 总结145. 其它14文档类别使用对象文档类别该文档是通用软件公司的关系型数据库的设计规,是技术文档。
使用对象该文档使用人员包括:➢开发本部总经理➢各产品部、事业部的经理、项目经理、设计人员➢软件中心负责人、设计人员➢公司总经理1.概述1.1 简介本文档总结了公司进行多年来的SYBASE数据库设计经验,目的将公司进行数据库设计的经验积累下来,实现设计经验的复用,为项目评审与项目质量保证提供进行检查的依据。
本规从数据库设计的目的、数据库的各个特征、数据库的规化等各个方面进行论述,对进行SYBASE数据库的设计提供了很好的依据。
MySQL数据库设计规范
MySQL数据库设计规范1、数据库命名规范采⽤26个英⽂字母(区分⼤⼩写)和0-9的⾃然数(经常不需要)加上下划线'_'组成;命名简洁明确(长度不能超过30个字符);例如:user, stat, log, 也可以wifi_user, wifi_stat, wifi_log给数据库加个前缀;除⾮是备份数据库可以加0-9的⾃然数:user_db_20151210;2、数据库表名命名规范采⽤26个英⽂字母(区分⼤⼩写)和0-9的⾃然数(经常不需要)加上下划线'_'组成;命名简洁明确,多个单词⽤下划线'_'分隔;例如:user_login, user_profile, user_detail, user_role, user_role_relation,user_role_right, user_role_right_relation表前缀'user_'可以有效的把相同关系的表显⽰在⼀起;3、数据库表字段名命名规范采⽤26个英⽂字母(区分⼤⼩写)和0-9的⾃然数(经常不需要)加上下划线'_'组成;命名简洁明确,多个单词⽤下划线'_'分隔;例如:user_login表字段 user_id, user_name, pass_word, eamil, tickit, status, mobile, add_time;每个表中必须有⾃增主键,add_time(默认系统时间)表与表之间的相关联字段名称要求尽可能的相同;4、数据库表字段类型规范⽤尽量少的存储空间来存数⼀个字段的数据;例如:能使⽤int就不要使⽤varchar、char,能⽤varchar(16)就不要使⽤varchar(256);IP地址最好使⽤int类型;固定长度的类型最好使⽤char,例如:邮编;能使⽤tinyint就不要使⽤smallint,int;最好给每个字段⼀个默认值,最好不能为null;5、数据库表索引规范命名简洁明确,例如:user_login表user_name字段的索引应为user_name_index唯⼀索引;为每个表创建⼀个主键索引;为每个表创建合理的索引;建⽴复合索引请慎重;6、简单熟悉数据库范式第⼀范式(1NF):字段值具有原⼦性,不能再分(所有关系型数据库系统都满⾜第⼀范式);例如:姓名字段,其中姓和名是⼀个整体,如果区分姓和名那么必须设⽴两个独⽴字段;第⼆范式(2NF):⼀个表必须有主键,即每⾏数据都能被唯⼀的区分;备注:必须先满⾜第⼀范式;第三范式(3NF):⼀个表中不能包涵其他相关表中⾮关键字段的信息,即数据表不能有沉余字段;备注:必须先满⾜第⼆范式;备注:往往我们在设计表中不能遵守第三范式,因为合理的沉余字段将会给我们减少join的查询;例如:相册表中会添加图⽚的点击数字段,在相册图⽚表中也会添加图⽚的点击数字段;MYSQL数据库设计原则1、核⼼原则不在数据库做运算;cpu计算务必移⾄业务层;控制列数量(字段少⽽精,字段数建议在20以内);平衡范式与冗余(效率优先;往往牺牲范式)拒绝3B(拒绝⼤sql语句:big sql、拒绝⼤事物:big transaction、拒绝⼤批量:big batch);2、字段类原则⽤好数值类型(⽤合适的字段类型节约空间);字符转化为数字(能转化的最好转化,同样节约空间、提⾼查询性能);避免使⽤NULL字段(NULL字段很难查询优化、NULL字段的索引需要额外空间、NULL字段的复合索引⽆效);少⽤text类型(尽量使⽤varchar代替text字段);3、索引类原则合理使⽤索引(改善查询,减慢更新,索引⼀定不是越多越好);字符字段必须建前缀索引;不在索引做列运算;innodb主键推荐使⽤⾃增列(主键建⽴聚簇索引,主键不应该被修改,字符串不应该做主键)(理解Innodb的索引保存结构就知道了);不⽤外键(由程序保证约束);4、sql类原则sql语句尽可能简单(⼀条sql只能在⼀个cpu运算,⼤语句拆⼩语句,减少锁时间,⼀条⼤sql可以堵死整个库);简单的事务;避免使⽤trig/func(触发器、函数不⽤客户端程序取⽽代之);不⽤select *(消耗cpu,io,内存,带宽,这种程序不具有扩展性);OR改写为IN(or的效率是n级别);OR改写为UNION(mysql的索引合并很弱智);select id from t where phone = ’159′ or name = ‘john’;=>select id from t where phone=’159′unionselect id from t where name=’jonh’避免负向%;慎⽤count(*);limit⾼效分页(limit越⼤,效率越低);使⽤union all替代union(union有去重开销);少⽤连接join;使⽤group by;请使⽤同类型⽐较;打散批量更新;5、性能分析⼯具show profile;mysqlsla;mysqldumpslow;explain;show slow log;show processlist;复制代码数据库的设计原则复制代码1. 原始单据与实体之间的关系 可以是⼀对⼀、⼀对多、多对多的关系。
11种重要的数据库设计规则-lixh
十一种重要的数据库设计规则2012年4月4日作者:Shivprasad2010年4月15日译者:lixh十一种重要的数据库设计规则 (1)简介 (2)规则1:应用的本质(OLTP或OLAP)? (2)规则2:数据进行逻辑分块,使你的生活更简单 (3)规则3:不要过多的使用规则2 (4)规则4:重复、无规则的数据将是你最大的敌人 (4)规则5:注意分离器的数据分离 (5)规则6:注意数据依赖 (7)规则7:重视派生列的选择 (8)规则8:如果注重性能,不要避开冗余数据 (8)规则9:多维数据区分于复杂数据 (9)规则10:名称-值表的设计 (10)规则11:无限制的自我参数等级数据PK和FK。
(11)译者话:我在网上无意中看到这篇文章,是中文版的,出自CSDN,当时我想收藏,但版主声明了转发需要他本人同意,所以我决定重新翻译此英文原文。
这篇文章写的真不错,可以好好的揣摩一下作者的深意,唯一让我感觉到不舒服的地方是作者太过方言化了,以至于部分句子我家的专业翻译也没弄明白。
由于本人能力有限,此文章只做参考,建立您阅读原文。
英文原文地址:/UploadFile/shivprasadk/11-important-database-designing-rules/# Introduction--------------------------------------------------------------------------------------------------------------------------------- 这篇文章将描述11种重要的数据库设计规则。
简介在读这篇文章之前,让我确认一下,我不是数据设计方面的大师,如下所示的十一点是我经过学习项目所获得到的经验。
我个人认为,在数据库设计过程中对我来说帮助很大。
欢迎任何批评。
我写这个完整的文章原因是,当开发者座下来设计一个数据库时,他们趋向于三种常规模式(“like a silver bullet.”没翻译成功,不知道是什么意思,应该是根深蒂固的意思吧)。
数据库建设规范标准[详]
数据库建设规目录1. 前言 (2)2. 围 (2)3. 术语和定义 (2)3.1式 (2)3.2关联 (2)3.3关系模型 (2)3.4视图 (3)3.5外键 (3)3.6约束 (3)3.7主键 (3)4. 命名规 (3)4.1规约定 (3)4.2表名 (4)4.3视图 (4)4.4存储过程 (4)4.5函数 (4)4.6触发器 (4)4.7字段 (4)4.8索引 (4)5. 数据库建设过程规 (5)5.1概述 (5)5.2需求分析阶段 (6)5.2.1需求调查 (6)5.2.2容分析 (6)5.3概念结构设计阶段 (6)5.2.1定义实体 (7)5.3.3定义关系 (7)5.3.4定义属性 (7)5.3.5定义键 (7)5.3.6定义索引 (8)5.3.7定义其他对象和规则 (8)5.4逻辑结构设计阶段 (8)5.5数据库物理设计阶段 (9)5.6实施、运行、维护规 (10)6. 数据库建设安全性规 (11)6.1概述 (11)6.2完整性设计 (11)6.3物理安全 (13)6.4访问控制 (13)6.5数据备份 (14)1. 前言数据库技术是信息资源管理最有效的手段。
数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求。
本规通过数据建库的命名、结构、建库过程及安全性措施等几个技术方面进行约定,目的就是提供一套规、合理、科学的建库技术体系,应用系统提供建库技术参考。
2. 围本规主要从关系数据库的命名、关系和结构以及建设过程等几个方面来规定数据库设计应遵循的规。
3. 术语和定义3.1式关系数据库中的关系是要满足一定要求的,满足不同程度要求的为不同式。
满足最低要求的叫第一式,简称 1NF。
在第一式中满足进一步要求的为第二式,其余以此类推。
一般而言,数据库的设计应至少满足第三式。
3.2关联关联是不同表之间的数据彼此联系的方法。
数据库设计指南
数据库设计指南数据库是现代信息系统中至关重要的一部分,数据库的设计能否合理与科学,直接影响着信息系统的性能、数据质量以及系统安全等方面。
如何进行数据库的设计呢?在此,我们将为大家详细讲解一下数据库设计指南。
1. 数据库需求分析首先,我们需要对数据库进行需求分析,明确系统所需要记录的信息内容、数据规模、数据结构和业务逻辑等方面。
在考虑数据库需求的过程中,我们要注意一下几点:1.了解用户需求:了解用户的需求非常重要,因为用户在使用数据库时会根据自己的实际需求选择相应的功能。
2.明确要存储的数据类型:在进行数据库设计之前,我们应该明确要存储的数据类型,因为不同的数据类型有不同的属性,有时候需要特殊处理。
3.规模的考虑:规模是数据库设计的一个重要方面,因为规模的变化会对数据库的性能产生影响。
在设计之前,需要对系统的数据量进行估计和预测。
2. 数据库设计范式在进行数据库设计时,必须要按照一定的规范进行,这就是数据库设计范式。
当前所使用的数据库设计范式主要有三种:第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。
1. 第一范式(1NF):第一范式是数据库设计的基础,它要求表中的每个属性都是原子性的,也就是不能再分解成更小的单位。
2. 第二范式(2NF):第二范式要求表中的非主键属性必须完全依赖于表的主键。
如果一个非主键属性依赖于表中的某个非主键属性,那么这个非主键属性就不满足第二范式。
3. 第三范式(3NF):第三范式要求表中的非主键属性必须只与主键相关,不能存在传递依赖关系。
如果一个非主键属性依赖于表中的其他非主键属性,那么这个非主键属性就不满足第三范式。
3. 数据库表结构数据库表的结构是指表中的各个字段,包括字段名称、数据类型、长度、约束、默认值等方面。
在进行数据库表设计时,我们需要注意以下几点:1. 命名规范:表的命名应该简洁明了,符合命名规范,便于程序员进行程序开发和维护。
2. 数据类型的选择:在选择数据类型时,应该根据实际需求来进行选择,同时更加注重查询效率和空间利用率。
数据库设计与规范化的原则
数据库设计与规范化的原则数据库设计是构建一个高效、可靠且易于维护的数据库系统的重要步骤。
规范化则是确保数据库中的数据达到最佳组织和结构的过程。
本文将探讨数据库设计与规范化的原则。
一、数据库设计原则1. 数据库需求分析:在设计数据库之前,首先需要进行数据库需求分析,了解业务需求、数据量估计、系统性能要求等。
通过深入了解需求,可以为数据库的设计提供明确的方向和目标。
2. 实体和关系建模:实体和关系建模是数据库设计的基础。
实体表示具有独立身份的对象,而关系则表示实体之间的联系。
常用的实体关系模型有实体关系图(E-R图)、关系模式、关系图等。
通过建立实体和关系的模型,可以清晰地描述数据库中的数据结构和关系。
3. 数据库范式理论:数据库设计中的规范化是一种优化数据结构的方法。
数据库范式理论定义了一系列规则,用于规范化数据库中的数据。
常见的数据库范式有第一范式(1NF)、第二范式(2NF)、第三范式(3NF)等。
遵循范式规则,可以减少数据冗余、提高数据的一致性和完整性。
4. 数据完整性:数据完整性是确保数据在数据库中的准确性和一致性的重要原则。
数据完整性可以通过定义数据的约束和触发器来实现。
例如,定义字段的数据类型、大小限制、主键约束、外键约束等,可以减少非法和不一致的数据。
二、规范化的原则1. 第一范式(1NF):确保每个数据库表中的字段都是原子的,即不可再分。
每个字段应该只包含一个值,避免重复的字段或包含多个值的字段。
2. 第二范式(2NF):在满足1NF的基础上,确保每个非主键字段都直接依赖于整个主键,而不是依赖于主键的一部分。
如果存在非主键字段与主键的部分依赖关系,应该将其分离到另一个表中。
3. 第三范式(3NF):在满足2NF的基础上,确保每个非主键字段都不传递依赖于主键。
如果存在非主键字段之间的传递依赖关系,应该将其分离到另一个表中。
4. 其他范式:除了1NF、2NF、3NF,还有更高级的范式,如BCNF(巴斯-科德范式)和4NF(第四范式)。
简述数据库设计原则
简述数据库设计原则数据库设计原则是指在设计数据库时需要遵循的一些基本规则和准则,以保证数据库的高效性、可靠性、可扩展性和易用性。
以下是一些常见的数据库设计原则:1. 数据库正规化原则:正规化是指将一个大的表分解成多个小的表,以消除数据冗余和避免数据更新异常。
正规化可以提高数据存储的效率和准确性,同时也可以降低数据管理的复杂度。
2. 数据库安全原则:在设计数据库时必须考虑到安全问题,包括对数据进行加密、权限控制、访问控制等措施,以保护数据不被非法访问或篡改。
3. 数据库备份与恢复原则:在设计数据库时需要考虑备份与恢复策略,以防止意外情况导致数据丢失或损坏。
备份策略包括定期备份和增量备份等方式,恢复策略包括完整恢复和部分恢复等方式。
4. 数据库性能优化原则:在设计数据库时需要考虑如何提高查询效率和响应速度,包括使用索引、优化查询语句、合理使用缓存等方法。
5. 数据库标准化原则:在设计数据库时需要遵循一些标准化的规范和约定,以保证数据的一致性和可维护性。
例如,使用统一的命名规则、数据类型、字段长度等。
6. 数据库可扩展性原则:在设计数据库时需要考虑未来的扩展需求,包括如何支持更多的用户、更大的数据量、更复杂的查询等。
因此,在设计时需要留出足够的空间和灵活性。
7. 数据库易用性原则:在设计数据库时需要考虑用户体验,包括如何简化操作流程、提高界面友好度、提供清晰明了的文档等。
总之,数据库设计原则是为了保证数据库能够满足业务需求,并且具有高效性、可靠性、可扩展性和易用性。
在具体实践中,还需要根据具体业务场景和技术要求进行适当调整和优化。
数据库表设计原则技巧
1. 原始单据与实体之间的关系可以是一对一、一对多、多对多的关系。
在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体。
在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单据对应多个实体,或多张原始单据对应一个实体。
这里的实体可以理解为基本表。
明确这种对应关系后,对我们设计录入界面大有好处。
〖例1〗:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表、社会关系表、工作简历表。
这就是“一张原始单据对应多个实体”的典型例子。
2. 主键与外键一般而言,一个实体不能既无主键又无外键。
在E-R 图中, 处于叶子部位的实体, 可以定义主键,也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。
主键与外键的设计,在全局数据库的设计中,占有重要地位。
当全局数据库的设计完成以后,有个美国数据库设计专家说:“键,到处都是键,除了键之外,什么也没有”,这就是他的数据库设计经验之谈,也反映了他对信息系统核心(数据模型)的高度抽象思想。
因为:主键是实体的高度抽象,主键与外键的配对,表示实体之间的连接。
3. 基本表的性质基本表与中间表、临时表不同,因为它具有如下四个特性:(1) 原子性。
基本表中的字段是不可再分解的。
(2) 原始性。
基本表中的记录是原始数据(基础数据)的记录。
(3) 演绎性。
由基本表与代码表中的数据,可以派生出所有的输出数据。
(4) 稳定性。
基本表的结构是相对稳定的,表中的记录是要长期保存的。
理解基本表的性质后,在设计数据库时,就能将基本表与中间表、临时表区分开来。
4. 范式标准基本表及其字段之间的关系, 应尽量满足第三范式。
但是,满足第三范式的数据库设计,往往不是最好的设计。
为了提高数据库的运行效率,常常需要降低范式标准:适当增加冗余,达到以空间换时间的目的。
〖例2〗:有一张存放商品的基本表,如表1所示。
“金额”这个字段的存在,表明该表的设计不满足第三范式,因为“金额”可以由“单价”乘以“数量”得到,说明“金额”是冗余字段。
数据库设计的重要原则
数据库设计的重要原则数据库设计是构建数据库原型的一个过程,该过程需要遵循一定的规则和原则。
了解和遵守数据库设计的重要原则可以帮助数据库设计人员创建一个优质的数据库,使其能够更好地满足用户需求,提高数据库的性能和稳定性,减少发生错误的几率。
下面将重点介绍一些数据库设计的重要原则。
1. 规范化规范化是数据库设计的基础和核心。
它的主要目的是通过去除数据冗余和维护一组表之间的逻辑关系,提高数据库的性能和可维护性。
数据冗余是指在多个表中保存相同数据的情况,这会导致数据更新和维护难度增大,浪费存储空间,影响数据库性能。
规范化的过程将重复数据分解到相关表中,以减少数据的冗余和重复。
2. 数据库安全性数据库安全性是数据库设计的一个非常重要的方面,尤其是在面对一些敏感数据的时候。
为了保护用户的隐私和机密性,数据库设计的人员必须采取各种措施来确保数据库的安全性,比如用户验证和鉴别,数据加密,网络安全等。
这些措施可以帮助防止非法入侵,保护数据的完整性和可靠性。
3. 数据库性能数据库性能是另一个非常重要的设计原则,它涉及到数据库的速度、可扩展性和容错性。
数据的持久性、高效查询和并发控制等方面都会影响数据库的性能。
为了保证数据库的效率,数据库设计人员需要考虑合理的数据结构、索引的使用、数据的压缩等方案。
4. 数据库架构数据库架构是数据库设计的另一个核心原则。
它是指数据的组织形式、结构和数据流。
数据库架构的目的是为数据库的本质特征提供支持,促进数据库的可维护性、可扩展性和最终的功能性。
合理的数据库架构可以使数据库系统具有更高的可靠性和灵活性。
5. 数据库备份和恢复数据库备份和恢复是数据库设计人员必须考虑的最后一个原则。
在数据库中,数据的安全性是至关重要的。
需要定期对数据库进行备份,以应对各种灾害和故障,比如机器故障、数据丢失、操作者失误等。
此外,恢复可以帮助数据库维护人员在必要时快速恢复数据库的原始状态,并保护数据的完整性和功能性。
数据库设计的原则和规范
数据库设计的原则和规范在进行数据库设计时,遵循一定的原则和规范是至关重要的。
良好的数据库设计可以提高系统的性能,保证数据的完整性和一致性,并且方便后续的维护和扩展。
本文将介绍一些数据库设计的原则和规范,供读者参考。
一、遵循范式设计原则范式是数据库设计中的一个重要概念,它定义了关系型数据库中数据的组织方式。
遵循范式设计原则可以提高数据库的灵活性和规范性。
常见的范式有第一范式、第二范式和第三范式。
第一范式要求数据列是原子性的,即每个数据列都不能再分解为更小的数据单元。
这样可以确保数据的完整性和一致性。
第二范式要求数据库表中的每个非主键列都必须完全依赖于主键。
如果存在非主键列只依赖于部分主键的情况,就需要将相关的非主键列提取出来创建新的表。
第三范式要求数据库表中的每个非主键列都必须直接依赖于主键,而不能依赖于其他非主键列。
这样可以避免数据冗余和更新异常。
二、选择合适的数据类型在数据库设计中,选择合适的数据类型对保证数据的准确性和查询效率起着重要的作用。
不同的数据库管理系统提供了不同的数据类型,需要根据实际需求选择合适的数据类型。
例如,在存储整数数据时,可以选择int类型来节省存储空间和提高查询效率;而在存储小数时,可以选择float或double类型来确保精度;在存储字符串时,根据字符串的长度选择合适的varchar或char类型。
三、避免使用保留字和特殊字符在数据库设计过程中,应避免使用保留字和特殊字符作为表名、字段名或约束名。
这样可以避免在查询和更新数据时出现语法错误或歧义。
通常,数据库管理系统会提供一份保留字的列表,设计人员可以参考该列表避免使用其中的保留字。
此外,还应避免使用特殊字符,以免引起解析错误或与系统命令冲突。
四、设立适当的索引索引是提高数据库查询性能的重要手段。
在数据库设计中,应设立适当的索引来加快数据的检索速度。
一般来说,可以对主键字段和常用于查询的字段建立索引。
然而,索引也会增加数据库的存储空间和维护成本。
数据库设计参考标准
数据库设计参考标准数据库设计参考标准文档控制文档属性文档修订历史[1]数据库设计参考标准一、概述为明确公司项目中数据库逻辑设计及物理设计的内容和流程,特制定本规范,供数据库设计、开发及维护人员参考。
数据库设计方法目前可分为四类:直观设计法、规范设计法、计算机辅助设计法和自动化设计法。
新奥尔良法是目前公认的比较完整和权威的一种规范设计法。
新奥尔良法将数据库设计分成需求分析(分析用户需求)、概念设计(信息分析和定义)、逻辑设计(设计实现)和物理设计(物理数据库设计)。
目前,常用的规范设计方法大多起源于新奥尔良法,并在设计的每一阶段采用一些辅助方法来具体实现.以下是两种常用的规范设计方法:1. 基于E—R模型的数据库设计方法。
该方法是由P.P。
S。
chen于1976年提出的数据库设计方法,其基本思想是在需求分析的基础上,用E-R(实体—联系)图构造一个反映现实世界实体之间联系的企业模式,然后再将此企业模式转换成基于某一特定的DBMS的概念模式。
2. 基于3NF的数据库设计方法。
该方法是由S·Atre提出的结构化设计方法,其基本思想是在需求分析的基础上,确定数据库模式中的全部属性和属性间的依赖关系,将它们组织在一个单一的关系模式中,然后再分析模式中不符合3NF的约束条件,将其进行投影分解,规范成若干个3NF关系模式的集合。
其具体设计步骤分为五个阶段:(1)设计企业模式,利用规范化得到的3NF关系模式画出企业模式;(2)设计数据库的概念模式,把企业模式转换成DBMS所能接受的概念模式,并根据概念模式导出各个应用的外模式;(3)设计数据库的物理模式(存储模式);(4)对物理模式进行评价;(5)实现数据库。
备注:数据库设计规范、数据编程规范、数据库物理设计规范中以Oracle 数据库为例,其它结构的数据库类似.二、数据库设计流程[2]数据库设计参考标准以规范性设计为例,把数据库设计流程分为以下几个阶段.(一) 需求分析阶段1. 需求收集和分析,得到数据字典描述的数据需求和数据流图描述的处理需求。
数据库设计规范_命名规范
数据库设计规范(命名规范)1 目的规范数据库设计。
2 概述从数据库的设计原则设计文档几方面论述数据库设计的规范思想及命名规则。
3 数据库应用结构根据对一般业务系统的分析,将数据库和程序系统统一进行整体描述,展示数据库的表之间以及与程序模块间的关系。
3.1 数据表和程序模块的分类根据“处理特点”,将数据表和程序模块进行分类如下:数据表分类:业务数据表、基本编码表、辅助编码表、系统信息表、累计数据表、结算数据表、决策数据表。
程序模块分类:初始化、业务处理、完整性检测与修正、结算处理、统计处理。
3.1.1 数据表分类说明业务数据表:记录业务发生的过程和结果。
如,合同、出仓单、申请单、凭证。
基本编码表:描述业务实体的基本信息和编码。
如,产品、客户、供应商、雇员。
辅助编码表:描述属性的列表值。
如,合同类型、职称、民族、付款方式。
系统信息表:存放与系统操作、业务控制有关的参数。
如,用户信息、权限、用户配置信息、成本核算方式。
累计数据表:存放业务的当前值和累计值。
如,当前库存、当前存款、累计销售、累计支出、应收账款。
结算数据表:存放各个时期末的结存数。
如,月末库存、月末银行存款、应收账款月结。
决策数据表:存放各个时期内发生的统计值。
如,月销售统计、月回款统计、出入库统计。
3.1.2 程序模块分类说明初始化:系统运行前对系统进行数据的初始化。
如,库存初始化。
业务处理:业务过程的控制和结果记录。
如,合同录入、费用审批、出入库。
完整性检测与修正:对累计数据表进行检查并自动修正。
如对当前库存、当前存款、累计销售的检查和重新计算。
结算处理:计算并记录各个时期末的结存数。
库存月结、应收账款月结。
统计处理:计算并记录各个时期内发生的统计数。
如,统计月销售、统计月回款、统计出入库。
3.2 数据表间的关系业务数据表<-->基本编码表主-外键关系。
如,合同表<-->客户编码表;业务数据表<-->辅助编码表主-外键关系。
数据库系统设计原则
数据库系统设计原则数据库系统设计是构建高效、可靠和灵活的数据库系统的关键步骤。
在设计数据库系统时,需要遵循一些重要的原则,以确保数据库的稳定性和性能。
以下是数据库系统设计的一些原则:1. 数据规范化数据规范化是将数据库设计为多个相关表的过程。
通过将数据分解为更小、更规范化的部分,可以减少数据冗余,提高数据库的组织性和维护性。
常用的数据规范化形式包括第一范式(1NF)、第二范式(2NF)和第三范式(3NF)。
2. 数据完整性数据完整性是指数据库中数据的准确性和一致性。
为了确保数据完整性,可以使用约束和验证规则来限制和验证用户输入的数据。
常见的数据完整性保证方式包括主键约束、外键约束、唯一性约束、默认值约束等。
3. 数据安全数据安全是保护数据库中敏感数据不被未经授权的访问、修改或破坏的重要方面。
为了确保数据安全,可以采取一些措施,如合适的访问控制,加密和备份策略。
此外,还可以使用强密码和定期更新以增加数据库的安全性。
4. 性能优化性能优化是确保数据库系统运行高效的关键步骤。
为了提高数据库的性能,可以考虑以下方面:选择合适的索引,避免不必要的查询,合理设计数据库查询语句,定期清理无用的数据和索引,以及合理调整数据库服务器的配置参数。
5. 缓存和存储优化缓存和存储优化是通过合理利用内存和硬盘资源来提高数据库的性能和响应速度。
可以通过使用缓存技术,如内存数据库或缓存服务器,来减少对磁盘IO的访问和提高数据的读取速度。
此外,还可以优化存储结构和使用合适的存储引擎来提高数据库的效率。
6. 容灾和备份策略容灾和备份策略是确保数据库系统对意外事故和故障具有恢复能力的关键措施。
应定期备份数据库,并将备份数据存储在安全的位置。
同时,应规划好容灾策略,保证在主服务器宕机或数据损坏时能够快速切换到备份服务器,并保证数据的连续性和可用性。
7. 灵活性和可扩展性灵活性和可扩展性是数据库系统设计中的重要考虑因素。
数据库应具备良好的扩展能力,以适应业务的发展和增长。
数据库表 名称创建规则
数据库表名称创建规则数据库表的命名是数据库设计中非常重要的一部分,良好的命名规则可以提高代码可读性、易于维护和使用。
下面是一些常用的数据库表名称创建规则的参考内容:1. 使用单数名词:表名通常使用单数名词,例如:`user`、`order`、`product`等。
这样命名规则可以更好地与实际对象对应,更易于理解。
2. 使用小写字母:表名应该使用小写字母,避免使用大写字母或者混合大小写的命名方式。
这样可以提高跨平台的兼容性,避免在不同数据库中出现大小写不一致的问题。
3. 使用下划线命名法:表名使用下划线命名法,即单词之间用下划线分隔,例如:`user_info`、`product_detail`等。
这种命名规则可以提高可读性,使表名更加清晰、易于理解。
4. 使用有意义的表名:表名应该具备描述性,能够准确反映表中数据的含义。
避免使用模糊、不具备描述性的名词和缩写的表名,例如:`tb1`、`dt2`等。
一个好的表名应该能够让其他开发人员一目了然地了解该表的作用和含义。
5. 避免使用保留字:避免使用数据库系统中的保留字作为表名,以免引起命名冲突和错误。
可以通过查阅相关数据库的保留字列表来避免使用这些保留字作为表名。
6. 使用清晰的单词组合:表名可以使用多个单词组合,以更好地描述表所包含的数据。
例如,可以将多个单词组合在一起来命名表名,例如:`user_address`、`product_category`等。
这样可以增加表名的表达力,能够更好地反映表的结构和功能。
7. 避免过长的表名:尽量避免使用过长的表名,以免在编程中不方便使用和书写。
一般来说,表名的长度应该控制在30个字符以内。
8. 使用一致的命名风格:在整个数据库设计中,应该保持表名的命名风格一致,以便于统一管理和维护。
例如,可以统一使用下划线命名法,并且遵循相同的表名前缀或后缀。
总而言之,数据库表的命名规则是一个非常重要的方面,可以通过使用单数名词、小写字母、下划线命名法、有意义的表名、避免使用保留字、使用清晰的单词组合、避免过长的表名和保持一致的命名风格等方式来创建规范的表名,提高数据库的可读性和可维护性。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
11-个重要的数据库设计规则
•简介
在您开始阅读这篇文章之前,我得明确地告诉您,我并不是一个数据库设计领域的大师。
以下列出的11点是我对自己在平时项目实践和阅读中学习到的经验总结出来的个人见解。
我个人认为它们对我的数据库设计提供了很大的帮助。
实属一家之言,欢迎拍砖: )
我之所以写下这篇这么完整的文章是因为,很多开发者一参与到数据库设计,就会很自然地把“三范式”当作银弹一样来使用。
他们往往认为遵循这个规范就是数据库设计的唯一标准。
由于这种心态,他们往往尽管一路碰壁也会坚持把项目做下去。
如果你对“三范式”不清楚,请点击这里(FQ)一步一步的了解什么是“三范式”。
大家都说标准规范是重要的指导方针并且也这么做着,但是把它当作石头上的一块标记来记着(死记硬背)还是会带来麻烦的。
以下11点是我在数据库设计时最优先考虑的规则。
•规则1:弄清楚将要开发的应用程序是什么性质的(OLTP 还是OPAP)?
当你要开始设计一个数据库的时候,你应该首先要分析出你为之设计的应用程序是什么类型的,它是“事务处理型”(Transactional)的还是“分析型”(Analytical)的?你会发现许多开发人员采用标准化做法去设计数据库,而不考虑目标程序是什么类型的,这样做出来的程序很快就会陷入性能、客户定制化的问题当中。
正如前面所说的,这里有两种应用程序类型,“基于事务处理”和“基于分析”,下面让我们来了解一下这两种类型究竟说的是什么意思。
事务处理型:这种类型的应用程序,你的最终用户更关注数据的增查改删(CRUD,Creating/Reading/Updating/Deleting)。
这种类型更加官方的叫法是“OLTP”。
分析型:这种类型的应用程序,你的最终用户更关注数据分析、报表、趋势预测等等功能。
这一类的数据库的“插入”和“更新”操作相对来说是比较少的。
它们主要的目的是更加快速地查询、分析数据。
这种类型更加官方的叫法是“OLAP”。
那么换句话说,如果你认为插入、更新、删除数据这些操作在你的程序中更为突出的话,那就设计一个规范化的表否则的话就去创建一个扁平的、不规范化的数据库结构。
以下这个简单的图表显示了像左边Names和Address这样的简单规范化的表,怎么通过应用不规范化结构来创建一个扁平的表结构。
•规则2:将你的数据按照逻辑意义分成不同的块,让事情做起来更简单
这个规则其实就是“三范式”中的第一范式。
违反这条规则的一个标志就是,你的查询使用了很多字符串解析函数
例如substring、charindex等等。
若真如此,那就需要应用这条规则了。
比如你看到的下面图片上有一个有学生名字的表,如果你想要查询学生名字中包含“Koirala”,但不包含“Harisingh”的记录,你可以想象一下你将会得到什么样的结果。
所以更好的做法是将这个字段拆分为更深层次的逻辑分块,以便我们的表数据写起来更干净,以及优化查询。
•规则3:不要过度使用“规则2”
开发者都是一群很可爱的生物。
如果你告诉他们这是一条解决问题的正路,他们就会一直这么做下去,做到过了头导致了一些不必要的后果。
这也可以应用于我们刚刚在前面提到的规则2。
当你考虑字段分解时,先暂停一下,并且问问你自己是否真的需要这么做。
正如所说的,分解应该是要符合逻辑的。
例如,你可以看到电话号码这个字段,你很少会把电话号码的ISD代码单独分开来操作(除非你的应用程序要求这么做)。
所以一个很明智的决定就是让它保持原样,否则这会带来更多的问题。
•规则4:把重复、不统一的数据当成你最大的敌人来对待
集中那些重复的数据然后重构它们。
我个人更加担心的是这些重复数据带来的混乱而不是它们占用了多少磁盘空间。
例如下面这个图表,你可以看到"5th Standard" 和"Fifth
standard" 是一样的意思,它们是重复数据。
现在你可能会说是由于那些录入者录入了这些重复的数据或者是差劲的验证程序没有拦住,让这些重复的数据进入到了你的系统。
现在,如果你想导出一份将原本在用户眼里十分困惑的数据显示为不同实体数据的报告,该怎么做呢?
解决方法之一是将这些数据完整地移到另外一个主表,然后通过外键引用过来。
在下面这个图表中你可以看到我们是如何创建一个名为“Standards”(课程级别)的主表,然后同样地使用简单的外键连接过去。
•规则5:当心被分隔符分割的数据,它们违反了“字段不可再分”
前面的规则2即“第一范式”说的是避免“重复组”。
下面这个图表作为其中的一个例子解释了“重复组”是什么样子的。
如果你仔细的观察syllabus(课程)这个字段,会发现在这一个字段里实在是填充了太多的数据了。
像这些字段就被称为“重复组”了。
如果我们又得必须使用这些数据,那么这些查询将会十分复杂并且我也怀疑这些查询会有性能问题。
这些被塞满了分隔符的数据列需要特别注意,并且一个较好的办法是将这些字段移到另外一个表中,使用外键连接过去,同样地以便于更好的管理。
那么,让我们现在就应用规则2(第一范式)“避免重复组”吧。
你可以看到上面这个图表,我创建了一个单独的syllabus(课程)表,然后使用“多对多”关系将它与subject(科目)表关联起来。
通过这个方法,主表(student表)的syllabus(课程)字段就不再有重复数据和分隔符了。
•规则6:当心那些仅仅部分依赖主键的列
留心注意那些仅仅部分依赖主键的列。
例如上面这个图表,我们可以看到这个表的主键是Roll No.+Standard。
现在请仔细观察syllabus 字段,可以看到syllabus(课程)字段仅仅关联(依赖)Standard(课程级别)字段而不是直接地关联(依赖)某个学生(Roll No. 字段)。
Syllabus(课程)字段关联的是学生正在学习的哪个课程级别(Standard字段)而不是直接关联到学生本身。
那如果明天我们要更新教学大纲(课程)的话还要痛苦地为每个同学也修改一下,这明显是不符合逻辑的(不正常的做法)。
更有意义的做法是将这些字段从这个表移到另外一个表,然后将它们与Standard(课程级别)表关联起来。
你可以看到我们是如何移动syllabus(课程)字段并且同样地附上
Standard 表。
这条规则只不过是“三范式”里的“第二范式”:“所有字段都必须完整地依赖主键而不是部分依赖”。
•规则7:仔细地选择派生列
如果你正在开发一个OLTP 型的应用程序,那强制不去使用派生字段会是一个很好的思路,除非有迫切的性能要求,比如经常需要求和、计算的OLAP 程序,为了性能,这些派生字段就有必要存在了。
通过上面的这个图表,你可以看到Average 字段是如何依赖Marks 和Subjects 字段的。
这也是冗余的一种形式。
因此对于这样的由其他
字段得到的字段,需要思考一下它们是否真的有必要存在。
这个规则也被称为“三范式”里的第三条:“不应该有依赖于非主键的列”。
我的个人看法是不要盲目地运用这条规则,应该要看实际情况,冗余数据并不总是坏的。
如果冗余数据是计算出来的,看看实际情况再来决定是否应用这第三范式。
•规则8:如果性能是关键,不要固执地去避免冗余
不要把“避免冗余”当作是一条绝对的规则去遵循。
如果对性能有迫切的需求,考虑一下打破常规。
常规情况下你需要做多个表的连接操作,而在非常规的情况下这样的多表连接是会大大地降低性能的。
•规则9:多维数据是各种不同数据的聚合
OLAP 项目主要是解决多维数据问题。
比如你可以看看下面这个图表,
你会想拿到每个国家、每个顾客、每段时期的销售额情况。
简单的说你正在看的销售额数据包含了三个维度的交叉。
为这种情况做一个实际的设计是一个更好的办法。
简单的说,你可以创建一个简单的主要销售表,它包含了销售额字段,通过外键将其他所有不同维度的表连接起来。
•规则10:将那些具有“名值表”特点的表统一起来设计
很多次我都遇到过这种“名值表”。
“名值表”意味着它有一些键,这些键被其他数据关联着。
比如下面这个图表,你可以看到我们有
Currency(货币型)和Country(国家)这两张表。
如果你仔细观察你
会发现实际上这些表都只有键和值。
对于这种表,创建一个主要的表,通过一个Type(类型)字段来区分不同的数据将会更有意义。
•规则11:无限分级结构的数据,引用自己的主键作为外键
我们会经常碰到一些无限父子分级结构的数据(树形结构?)。
例如考虑一个多级销售方案的情况,一个销售人员之下可以有多个销售人员。
注意到都是“销售人员”。
也就是说数据本身都是一种。
但是层级不同。
这时候我们可以引用自己的主键作为外键来表达这种层级关系,从而达成目的。
这篇文章的用意不是叫大家不要遵循范式,而是叫大家不要盲目地遵循范式。
根据你的项目性质和需要处理的数据类型来做出正确的选择。