数据库设计规范在系统设计中，对数据库的设计应考虑哪些设计原则？

理解什么是数据库规范化

规范化是对数据库数据进行有效组织的过程。

规范化过程的两个主要目的是：消除冗余数据(如把相同的数据存储在超过一个表里)和确保数据的依赖性处于有效状态(相关数据只存储在一个表里)。

这两个目标的实现很有意义，因为能够减少数据库和表的空间消耗，并确保数据存储的一致性和逻辑性。

范式 国际数据库界制定了一系列构建数据库必须遵循的特殊规则，以确保数据库的规范化。

在关系数据库里，这种规则就是范式，在数据库的世界里用数字来定义不同级别的范式，从低到高共分为五种：第一范式(简称1NF)、第二范式(2NF)、第三范式(3NF)、第四范式(4NF)和第五范式(5NF)。

第一范式需要满足的要求最低，第二范式在第一范式的基础上增加了更多的要求，以此类推。

在实际应用当中，最常见的是第一范式、第二范式和第三范式

数据库设计主要包括哪几部分，分别包括哪些内容

数据库设计主要包括需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库的实施和数据库的运行和维护，具体内容如下： 1、需求分析 内容：调查和分析用户的业务活动和数据的使用情况，弄清所用数据的种类、范围、数量以及它们在业务活动中交流的情况，确定用户对数据库系统的使用要求和各种约束条件等，形成用户需求规约。

2、概念设计 内容：对用户要求描述的现实世界，通过对其中诸处的分类、聚集和概括，建立抽象的概念数据模型。

这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。

3、逻辑设计 内容：主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。

与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。

这一步设计的结果就是所谓“逻辑数据库”。

4、物理设计 内容：根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。

5、验证设计 内容：收集数据并具体建立一个数据库，运行一些典型的应用任务来验证数据库设计的正确性和合理性。

一般，一个大型数据库的设计过程往往需要经过多次循环反复。

当设计的某步发现问题时，可能就需要返回到前面去进行修改。

6、运行与维护设计 内容：在数据库系统正式投入运行的过程中，必须不断地对其进行调整与修改。

除了关系型数据库已有一套较完整的数据范式理论可用来部分地指导数据库设计之外，尚缺乏一套完善的数据库设计理论、方法和工具，以实现数据库设计的自动化或交互式的半自动化设计。

扩展资料： 重要性 1、有利于资源节约 对计算机软件数据库设计加以重视不仅可减少软件后期的维修，达到节约人力与物力的目的，同时还有利于软件功能的高效发挥。

2、有利于软件运行速度的提高 高水平的数据库设计可满足不同计算机软件系统对于运行速度的需求，而且还可充分发挥并实现系统功能。

计算机软件性能提高后，系统发出的运行指令在为用户提供信息时也将更加快速有效，软件运行速度自然得以提高。

3、有利于软件故障的减少 加强数据库设计可有效减少软件故障的发生几率，推动计算机软件功能的实现。

参考资料来源：百度百科-数据库设计

理解什么是数据库规范化

优点是降低冗余，利于保证数据的一致性和完整性； 缺点是过度的规范化，易造成查询和统计时的效率下降，这主要是由于多表连接所造成的问题。

适当的反规范化设计可以提高效率，但最好在那些数据不太发生变化的情况下使用。

通常情况下，可以从两个方面来判断数据库是否设计的比较规范。

一是看看是否拥有大量的窄表，二是宽表的数量是否足够的少。

若符合这两个条件，则可以说明这个数据库的规范化水平还是比较高的。

当然这是两个泛泛而谈的指标。

为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求。

　　要求一：表中应该避免可为空的列。

　　虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。

数据库在处理的时候，需要进行特殊的处理。

如此的话，就会增加数据库处理记录的复杂性。

当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。

　　所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。

若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。

　　一是通过设置默认值的形式，来避免空字段的产生。

如在一个人事管理系统中，有时候身份证号码字段可能允许为空。

因为不是每个人都可以记住自己的身份证号码。

而在员工报到的时候，可能身份证没有带在身边。

所以，身份证号码字段往往不能及时提供。

为此，身份证号码字段可以允许为空，以满足这些特殊情况的需要。

但是，在数据库设计的时候，则可以做一些处理。

如当用户没有输入内容的时候，则把这个字段的默认值设置为0或者为N/A。

以避免空字段的产生。

　　二是若一张表中，允许为空的列比较多，接近表全部列数的三分之一。

而且，这些列在大部分情况下，都是可有可无的。

若数据库管理员遇到这种情况，笔者建议另外建立一张副表，以保存这些列。

然后通过关键字把主表跟这张副表关联起来。

将数据存储在两个独立的表中使得主表的设计更为简单，同时也能够满足存储空值信息的需要。

　　要求二：表不应该有重复的值或者列。

　　 　　为了解决这个问题，有多种实现方式。

但是，若设计不合理的话在，则会导致重复的值或者列。

如我们也可以这么设计，把客户信息、联系人都放入同一张表中。

为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。

若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。

　　 　　所以，在数据库设计的时候要尽量避免这种重复的值或者列的产生。

笔者建议，若数据库管理员遇到这种情况，可以改变一下策略。

如把客户联系人另外设置一张表。

然后通过客户ID把供应商信息表跟客户联系人信息表连接起来。

也就是说，尽量将重复的值放置到一张独立的表中进行管理。

然后通过视图或者其他手段把这些独立的表联系起来。

　　要求三：表中记录应该有一个唯一的标识符。

　　在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分。

每个表都应该有一个ID列，任何两个记录都不可以共享同一个ID值。

另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。

否则的话，很容易产生ID值不统一的情况。

　　 　　要求四：数据库对象要有统一的前缀名。

　　一个比较复杂的应用系统，其对应的数据库表往往以千计。

若让数据库管理员看到对象名就了解这个数据库对象所起的作用，恐怕会比较困难。

而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。

　　 　　其次，表、视图、函数等最好也有统一的前缀。

如视图可以用V为前缀，而函数则可以利用F为前缀。

如此数据库管理员无论是在日常管理还是对象引用的时候，都能够在最短的时间内找到自己所需要的对象。

　　要求五：尽量只存储单一实体类型的数据。

　　这里将的实体类型跟数据类型不是一回事，要注意区分。

这里讲的实体类型是指所需要描述对象的本身。

笔者举一个例子，估计大家就可以明白其中的内容了。

如现在有一个图书馆里系统，有图书基本信息、作者信息两个实体对象。

若用户要把这两个实体对象信息放在同一张表中也是可以的。

如可以把表设计成图书名字、图书作者等等。

可是如此设计的话，会给后续的维护带来不少的麻烦。

　 　　遇到这种情况时，笔者建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、作者基本信息表、图书与作者对应表等等。

如此设计以后，以上遇到的所有问题就都引刃而解了。

　　以上五条是在数据库设计时达到规范化水平的基本要求。

除了这些另外还有很多细节方面的要求，如数据类型、存储过程等等。

而且，数据库规范往往没有技术方面的严格限制，主要依靠数据库管理员日常工作经验的累积。

第一范式每个分量不可再分 第一范式消除了非主属性对键的部分函数依赖, 就是第二范式 第二范式消除了任何属性对键的传递依赖, 就是第三范式~

在系统设计中，对数据库的设计应考虑哪些设计原则？

数据库是整个软件应用的根基，是软件设计的起点，它起着决定性的质变作用，因此我们必须对数据库设计高度重视起来，培养设计良好数据库的习惯，是一个优秀的软件设计师所必须具备的基本素质条件！ 　那么我们要做到什么程度才是对的呢？下面就说说数据库设计的原则： 　　1、数据库设计最起码要占用整个项目开发的40%以上的时间 　　数据库是需求的直观反应和表现，因此设计时必须要切实符合用户的需求，要多次与用户沟通交流来细化需求，将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。

如果需求不明确，就要分析不确定的因素，设计表时就要事先预留出可变通的字段，正所谓“有备无患”。

　　2、数据库设计不仅仅停留于页面demo的表面 　　页面内容所需要的字段，在数据库设计中只是一部分，还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段，因此数据库设计绝对不是简单的基本数据存储，还有逻辑数据存储。

　　3、数据库设计完成后，项目80%的设计开发在你脑海中就已经完成了 　　每个字段的设计都是有他必要的意义的，你在设计每一个字段的同时，就应该已经想清楚程序中如何去运用这些字段，多张表的联系在程序中是如何体现的。

换句话说，你完成数据库设计后，程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。

如果达不到这种程度，那当进入编码阶段后，才发现要运用的技术或实现的方式数据库无法支持，这时再改动数据库就会很麻烦，会造成一系列不可预测的问题。

　　4、数据库设计时就要考虑到效率和优化问题 　　一开始就要分析哪些表会存储较多的数据量，对于数据量较大的表的设计往往是粗粒度的，也会冗余一些必要的字段，已达到尽量用最少的表、最弱的表关系去存储海量的数据。

并且在设计表时，一般都会对主键建立聚集索引，含有大数据量的表更是要建立索引以提供查询性能。

对于含有计算、数据交互、统计这类需求时，还要考虑是否有必要采用存储过程。

　　5、添加必要的（冗余）字段 　　像“创建时间”、“修改时间”、“备注”、“操作用户IP”和一些用于其他需求（如统计）的字段等，在每张表中必须都要有，不是说只有系统中用到的数据才会存到数据库中，一些冗余字段是为了便于日后维护、分析、拓展而添加的，这点是非常重要的，比如黑客攻击，篡改了数据，我们便就可以根据修改时间和操作用户IP来查找定位。

　　6、设计合理的表关联 　　若多张表之间的关系复杂，建议采用第三张映射表来关联维护两张表之间的关系，以降低表之间的直接耦合度。

若多张表涉及到大数据量的问题，表结构尽量简单，关联也要尽可能避免。

　　7、设计表时不加主外键等约束性关联，系统编码阶段完成后再添加约束性关联 　　这样做的目的是有利于团队并行开发，减少编码时所遇到的问题，表之间的关系靠程序来控制。

编码完成后再加关联并进行测试。

不过也有一些公司的做法是干脆就不加表关联。

　　8、选择合适的主键生成策略