SQL Server 数据库设计

一、数据库设计的必要性

         在实际的软件项目中,如果系统中需要存储的数据量比较大,需要设计的表比较多,表与表之间的关系比较复杂,那我们就需要进行规范的数据库设置。如果不经过数据库的设计,我们构建的数据库不合理、不恰当,那么数据库的维护、运行效率会有很大的问题。这将直接影响到项目的运行性和可靠性。

二、什么是数据库设计

      数据库设计实际上就是规划和结构化数据库中的数据对象以及这些数据对象之间的关系过程。

三、数据库设计的重要性

      Ø 不经过设计的数据库或是设计糟糕的数据库很可能导致

            1、 数据库运行效率地下

            2、 更新、删除、添加数据出现问题

      Ø 良好设计的数据库

             1、 执行效率高

             2、 使应用程序更便于开发

             3、 扩展性好

             4、 维护性好

四、数据模型

        数据模型就像是数据间联系的一个轮廓图,整个模型就像一个框架。

       如果按照记录间联系的表示方式,对数据模型进行分类,可以分为:层次模型、网状模型、关系模型。前两种又称为格式化数据模型。数据模型的好坏直接影响到数据库的性能,所以数据模型的选择是数据库设计的首要任务。

       Ø 实体-关系(E-R)数据模型

              E-R数据模型(Entity-Relationship data model),即实体-关系数据模型。E-R数据模型不同于传统的关系数据模型,它不是面向实现,而是面向现实物体的。

       Ø 实体(Entity)

              数据是用来描述现实中的物体的,而描述的对象都是形形色色的,有具体的、也有抽象的;有物理上存在的、也有概念性的。凡是可以互相区别而且可以被人们认识的事、物、概念等统统抽象为实体。多个相同的类型的实体可以称为实体集(Entity set)。因此,在E-R数据模型中,也有型与值之分;实体可以作为型来定义,每个实体可以是它的实例和值。

       Ø 属性(Attribute)

              实体一般具体若干特征,这些特征称为实体的属性。而每个属性都有自己的取值范围,在E-R数据模型中称为值集(value set)。在同一实体集中,每个实体的属性及其值集都是相同的,但可能取不同的值。属性对应数据库表的列。

       Ø 关系(Relationship)

              实体之间会有各种关系,这些关系抽象为联系。不但实体可以有属性,关系也可以有属性。

五、数据库设计步骤

       Ø 数据库设计可以分为以下几个阶段

              1、 需求分析阶段:分析客户的业务需求,特别是数据方面的需求

              2、 概要设计阶段:绘制数据库的E-R图,并确认需求文档的正确性和完整性,E-R图是项目的设计人员、开发人员、测试人员,以及和客户进行沟通的重要凭据

              3、 详细设计阶段:将概要设计阶段的E-R图转换为数据库表,进行逻辑设计,确定各个表之间的主外键关系,运用数据库的三范式进行审核,并进行技术评审。最后决定选哪种数据库(Oracle、SQLServer、MySQL)来建库、建表。

       Ø 需求分析阶段:数据库系统分析

              秀气分析阶段的重点是调查、收集、分析客户的业务数据需求以及数据的安全性、完整性需求等。

       需求分析步骤:

              1、 确认业务需求

              2、 标识关系实体

              3、 标识每个实体的具有的属性

              4、 确认实体之间的关系

       Ø 概要设计阶段:绘制E-R图

              作为数据库设计者,你需要和项目组内其他成员分享你的设计思路,共同研讨数据库设计的合理性、安全性、完整性,并确认是否符合客户的业务需求。那么使用E-R图,这种图形化的表示方式最为直观。

              * E-R图中的实体、属性和关系

                     

              上面的简单E-R图可以看出用户和收支之间的关系。在上图中可以看出:用矩形表示实体,实体是一般名词;椭圆表示属性,一般也是名词;菱形表示关系,一般是动词。

              * 映射基数

              映射基数表示可以通过关系与该实体的个数。对于实体集A和B之间的二元关系,可能的映射基数有:

                     1、 一对一:也就是A实体中最多只有一个B实体的关联,而B实体的最多只有一个A实体的关联。用E-R图表示:

                           

                     2、 一对多:A实体可以与B实体任意数量的进行关联,B中的实体最多与A中的一个实体关联。E-R图表示:

                           

                     3、 多对一:A实体最多与一个B实体进行关联,而B实体可以和任意多个A实体进行关联。E-R图表示:

                           

                     4、 多对多:A实体可以有多个B实体,而B实体也可以有任意多个A实体。E-R图表示:

                           

              * E-R图

              E-R图可以以图形化的方式将数据库的整个逻辑结构表示出来,组成部分有:

                     1、 矩形表示实体集

                     2、 椭圆表示属性

                     3、 菱形表示关系、

                     4、 直线用来连接实体集与属性、实体集和关系

                     5、 直线箭头表示实体集之间映射基数

      Ø 详细设计阶段:将E-R图转换为表

            步骤如下:

                  1、 将各个实体转换为对应的表,将各属性转换为对应的列

                  2、 标识每张表的主键

                  3、 将实体之间的关系转换为表与表之间的主外键关系

六、数据库设计规范化

      Ø 数据库设计中经常出现的问题

            1、 数据冗余大

            2、 插入数据异常

            3、 删除异常

            4、 更新异常

      Ø 规范设计

            一个较好的关系数据库模型,它的每个关系中的属性一定要满足某种内在的语义条件,即要按一定的规范设计关系模型,这就是设计的规范化。

            在数据库设计时,有一些专门的规则,称为数据库的设计范式,遵循这些规则,就可以创建出良好的数据库,数据库著名的三大范式理论:

                  1、 第一范式(1NF)

                        第一范式是满足关系数据库模型所要遵循的最基本的条件范式,几关系中的每个属性必须是不可再分的简单项,不能是属性组合,即属性的取值是不可拆分的原子值。

                  2、 第二范式(2NF)

                        第二范式是在第一范式的基础上,确保表中的每列都和主键相关。其定义是如果一个关系满足1NF,并且除了主键关系外的其他列都依赖于该主键,则满足第二范式。

                  3、 第三范式(3NF)

                        第三范式是在第二范式的基础上进行的,第三范式的目标是确保每列都和主键列直接相关,而不是间接相关的。其定义是:如果一个关系满足2NF,并且除主键外的其他列都不传递依赖于该主键。

      Ø 规范化和性能关系

            为了满足三大范式,数据库的性能可能会有一定程度的降低。所以,在实际数据库设计中,我们既要尽量满足三大范式,从而避免数据冗余和各种数据库的操作异常,同时也要考虑数据的访问性能。有时候,为了提高数据库的访问效率,适当的允许少量数据冗余咧存在,才是最适合的数据库设计方案。

转自:http://blog.csdn.net/ibm_hoojo/article/details/6607952

这个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、付费专栏及课程。

余额充值