如何学习数据库知识

如何学好数据库编程？下面介绍一下本人的一些经验，仅供参考：

1首先要把原来一个数据一个数据、一条记录一条记录的数据处理方式忘掉，越彻底越好。

现在用成批处理了。少用记录集一条记录一条记录地处理，尽量用SQL语句。

2学好关系数据库的理论，尤其是规范化理论，表的设计一定要规范化，最起码要规范化到第三范式。集合运算(并、交、差)。关系运算(选择、投影、连接)。其中连接与规范化是紧密结合的。

3运用面向对象的技术：面向对象的分析OOA、面向对象的设计OOD、面向对象的编程OOP，根据表的关系，用窗体和子窗体、报表和子报表，仿真面向对象，这样可以增加程序的可读性和可维护性。(这是高级技术，同志们不要轻视，做大项目你就知道有用了)

4用查询时，通常一步做不出来，可以分几步做，本人通常是这么做的，从我给网友回复的例子中也可以看得出。为什么要这样做？(1)有些是SQL语言的限制，没办法一步做出来，逼的；(2)可以检查每一步查询的结果，容易调试；(3)增加可读性，便于日后维护。

5查询的结果用窗体显示或用报表打印，两者的技术差不多。通常改变打开窗体或报表的条件就可控制显示或打印的记录范围。另外用查询做数据源时，动态改变查询中的SQL语句，比在查询中引用窗体的控件要方便，因为SQL语句生成是在VBA中，可以先存放在字符变量中，然后再更新查询的SQL语句，这样就可以用断点来检查变量值对不对，如果在查询中引用窗体的控件，尤其是包含IIF()函数时，调试是很困难的。

6开发一个系统，首先要解决技术问题，即算法，用简单例子，把算法弄懂了，再详细设计，这一点从网友的提问中可以看出，有很多人问题表达不清楚，有的人其中夹了很多与算法无关的东西，尤其是很专业的东西，别人不容易看得明白，由于算法没搞清楚，程序就无法编了。

7不要使用过多的工具特性，使用过多的工具特性会使可读性降低，可维护性差，要别人帮忙时难以得到帮助，更要命的是可移植性差，从MDB到ADP就可以体会到了，所以在编程时可读性很重要，可移植性更重要，你甘心自己的程序就固定在一个环境下运行吗？你甘心永远用一个工具搞开发吗？为了你的“钱途”，不要玩弄太多的技巧，当然技术研究是另外一码事。

数据库设计中著名的三大范式。

1 第一范式（1NF）

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。 所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是无重复的列。

2 第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是唯一的，因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主键、主码。 第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。

3 第三范式（3NF）

满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。

以上就是关于如何学习数据库知识全部的内容，包括:如何学习数据库知识、为什么实验书中需要将数据库划分为5张表,根据什么数据库中的原理知识、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！