一、数据库范式
第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等，而不能为数组，集合等。
例如，如下的数据库表是符合第一范式的：
字段1 字段2 字段3 字段4 而这样的数据库表是不符合第一范式的：
字段1 字段2 字段3 字段4 字段3.1 字段3.2 很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。
第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。
假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
这个数据库表不满足第二范式，因为存在如下决定关系：
(课程名称) → (学分)
(学号) → (姓名, 年龄)
即存在组合关键字中的字段决定非关键字的情况。
由于不符合2NF，这个选课关系表会存在如下问题：
(1) 数据冗余：
同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
(2) 更新异常：
若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
(3) 插入异常：
假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
(4) 删除异常：
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
把选课关系表SelectCourse改为如下三个表：
学生：Student(学号, 姓名, 年龄)；
课程：Course(课程名称, 学分)；
选课关系：SelectCourse(学号, 课程名称, 成绩)。
这样的数据库表是符合第二范式的，消除了数据冗余、更新异常、插入异常和删除异常。
另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。
第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系：
关键字段 → 非关键字段x → 非关键字段y
假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：
(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)
这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系：
(学号) → (所在学院) → (学院地点, 学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
它也会存在数据冗余、更新异常、插入异常和删除异常的情况，读者可自行分析得知。
把学生关系表分为如下两个表：
学生：(学号, 姓名, 年龄, 所在学院)；
学院：(学院, 地点, 电话)。
这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。
鲍依斯-科得范式（BCNF）：在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。
假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现如下异常情况：
(1) 删除异常：
当仓库被清空后，所有"存储物品ID"和"数量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。
(2) 插入异常：
当仓库没有存储任何物品时，无法给仓库分配管理员。
(3) 更新异常：
如果仓库换了管理员，则表中所有行的管理员ID都要修改。
把仓库管理关系表分解为二个关系表：
仓库管理：StorehouseManage(仓库ID, 管理员ID)；
仓库：Storehouse(仓库ID, 存储物品ID, 数量)。
这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。
二、存储过程
存储过程是用户定义的一系列SQL语句的集合，涉及特定表或其他对象的任务，用户可以调用存储过程。而函数通常是数据库已定义的方法，它接受参数并返回某种类型的值（值或者是表），并且不涉及特定用户表。
然后一位朋友又在QQ上给我说了一下：
“存储过程就是你编写好的一个程序。函数就是软件自带的功能，可以调用，相当于方法，所以可以在某个语句中被调用。
存储过程可以有输出，oracle可以自定义函数，但自带函数已经很全了，在存储过程内部可以调用别的存储过程，数据库有事物隔离的，如果两个存储过程都对一张表进行修改是不能一起运行的，必须等一个事务commit了才能进行下一个。
存储过程自由度很大的，你可以做任何事，删表建表都可以。函数与用户与表无关,如果你用PL/SQL 开发工具，可以查看一张表被哪些存储过程引用，就是他说的涉及而函数不被表和其他对象所占有”
其实很多时候，你用过，就懂了，如果没用过，就要请教用过的人，有时候比看书的效率高很多。
三、事务
ACID
数据库的事务，是指为单个逻辑工作的单元执行的一系列操作。这些操作要么全做，要么全不做，是一个不可分割的工作单位。
原子性：操作是不可分割的；
一致性：不改变数据库中数据的一致性，比如A与B的和是10，那么A增加1，B就要减少1；
隔离性：两个事务不会出现交错执行的情况；
持久性：一旦事务完成，数据库会被拥挤更新。
四、SQL注入
攻击者把SQL命令插入到Web表单的输入域护着其他的一些请求字符串中，欺骗服务器执行恶心的SQL命令。
解决方法：在执行SQL命令前过滤一下用户的输入。
- 替换单引号：否则用户可能会输入’1’=’1’
- 删除用户输入内容中的所有连字符：如果输入--，会把后面的语句注释掉
- 用存储过程来执行所有的查询：SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。
- 限制表单或查询字符串输入的长度：如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。
- 检查用户输入的合法性，确信输入的内容只包含合法的数据：数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。
- 将用户登录名称、密码等数据加密保存：加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。
- 检查提取数据的查询所返回的记录数量：如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。
- 限制执行查找的数据库账户的权限。
五、索引
在关系数据库中，索引是一种与表有关的数据库结构，它可以使对应于表的SQL语句执行得更快。索引的作用相当于图书的目录，可以根据目录中的页码快速找到所需的内容。
聚集索引的顺序就是数据的物理存储顺序，所以一张表最多只能有一个聚集索引（不可能你的数据库的数据，既是从小到大排列，又是从大到小排列吧。而非聚集索引是与物理排列顺序无关的。
索引的实现通常使用B树及其变种B+树。
索引有一篇博客介绍的很详细（http://blog.csdn.net/kennyrose/article/details/7532032）
六、数据库锁
排它锁，共享锁，更新锁等…
这一篇博客整理的很详细（http://www.cnblogs.com/zhouqianhua/archive/2011/04/15/2017049.html）
ok，入门到此为止。