第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。简而言之，第三范式就是属性不依赖于其它非主属性。
所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。
因此，满足第三范式的数据库表应该不存在如下依赖关系：
关键字段 → 非关键字段x → 非关键字段y
我的问题是非关键字段X是仅仅指单个列还是说可以是多列的组合？
给一个碰到的例子，请问下这个是否属于3NF
积分历史记录表
log_id int(11)
action_type int(11) //记录产生积分的动作
source_id int(11) //产生积分的来源文章或问题
source_from int(11) //标记是文章或者问题
sender_user_id int(11) //产生用户动作的用户
recipient_user_id int(11) //产生积分变化的用户
现在上面的表是2NF是肯定没问题的，因为只有一个主键2NF
但是上述表存在这样一个传递依赖，
log_id->(action_type, source_id， source_from)->recipient_user_id
我的看法是这张表属于2NF的，不属于3NF
答案：X可以是多个列组合。
你的这一段表述有误：
关键字段 → 非关键字段x → 非关键字段y
这里的X是候选键（Condicate Key），不是非关键字段（Non-prime attribute），Key当然可以是多个列组成的，字段（或者说属性）自然不可能由多个列组成，所以，你用错了术语，把自己给绕进进去了。
另外，百度百科和《数据库系统原理》上的中文描述比较反人类，我是怎么读都不懂，反倒是一些博客作者，和英文维基百科上写得很清楚：
Codd's definition states that a table is in 3NF if and only if both of the following conditions hold:
* The relation R (table) is in second normal form (2NF)
* Every non-prime attribute of R is non-transitively dependent (i.e. directly dependent) on every superkey of R.
新问题解答：
我认为属于3NF。
- log_id，其实是代理键，无意义的数字主键，它和其它字段都不存在依赖关系
- 你所说的依赖关系不能成立，积分接收者怎么会由前面这三个字段决定呢？莫非你的意思是，积分接收者一定是问题或者文章的作者？这样的话，光sourceid和sourcefrom就能决定recipientuserid了，这样就确实不满足3NF
最后吐槽一下sf.gg的新版，回答问题时，为什么不给显示全文，一边写答案一边看问题（好顺手复制一些问题内容）是很正常的需求啊！@joyqi