杜工解决方法：将data目录设置在mysql安装目录下，可正常启动服务。

过程：安装msi文件，到最后一步配置时，可跳过，然后进入安装目录 /bin/下，找到MysqlInstanceConfig.exe，运行后，可按照提示一步一步配置。

Note that the MySQL client library is not bundled anymore.

首先使用命令find / -name ‘mysql.h’ 查找路径，如果找到就给with-mysql=赋上路径，如果找不到，那就是缺少了 mysql-devel 安装包，用yum或者rpm安装上，即可解决问题

操练开始

在我们做出测试代码之前，首先要创建一个用户数据表。运行如下语句：

create database myapp;
use myapp;
create table users (user varchar(60), pass varchar(60));

其中user用来储存用户名，pass用来储存密码的hash值。目前，phpass生成的密码hash值最大长度为60。

创建新用户

首先，我们从phpass项目网站把PasswordHash.php下载到网站目录中，并设置能让php加载的权限（Unix系统下一般为600或者644）。然后在网站目录中创建两个文件：user-man.html (644权限), and user-man.php (权限同asswordHash.php)。

下面，把下面的内容写在user-man.html中：

<form action="user-man.php" method="POST">
用户名:<br>
<input size="60"><br>
密码：<br>
<input size="60"><br>
<input value="创建新用户">
</form>

这个文件获取用户名和密码，然后提交到user-man.php。下面是user-man.php的代码：

header('Content-Type: text/plain');
 
// 本例只是简单的输出文本的hash值，所以开头要声明下，不让浏览器当作html解析。
 
 
 
require '../PasswordHash.php';
 
// Base-2 logarithm of the iteration count used for password stretching
$hash_cost_log2 = 8;
// Do we require the hashes to be portable to older systems (less secure)?
$hash_portable = FALSE;
 
//在实际应用中，上面两行最好写在配置文件中，比如config.inc.php
 
//下面开始获取提交的用户名和密码，实际应用中需要验证有效性，不再赘述。
 
$user = $_POST['user'];
$pass = $_POST['pass'];
 
//下面开始计算密码hash值
 
$hasher = new PasswordHash($hash_cost_log2, $hash_portable);
$hash = $hasher->HashPassword($pass);
if (strlen($hash) < 20)//这里用的CRYPT_EXT_DES方法，其它加密算法得到结果会更长。
    fail('Failed to hash new password');
unset($hasher);
 
function fail($pub, $pvt = '')
{
    $msg = $pub;
    if ($pvt !== '')
        $msg .= ": $pvt";
    exit("An error occurred ($msg).\n");
}
 
//下面开始把用户信息存入到数据库中
 
$db_host = 'localhost';
$db_port = 3306;
$db_user = ‘dbuser’;
$db_pass = 'dbpass';
$db_name = 'dbname';
 
//数据库信息也最好存储在配置文件中。下面开始连接数据库，并注意弹出失败信息。
 
$db = new mysqli($db_host, $db_user, $db_pass, $db_name, $db_port);
if (mysqli_connect_errno())
    fail('MySQL connect', mysqli_connect_error());
 
//下面用预备语句插入用户信息
 
($stmt = $db->prepare('insert into users (user, pass) values (?, ?)'))
    || fail('MySQL prepare', $db->error);
$stmt->bind_param('ss', $user, $hash)
    || fail('MySQL bind_param', $db->error);
$stmt->execute()
    || fail('MySQL execute', $db->error);
 
//最后数据库连接
 
$stmt->close();
$db->close();

好了，把左右文件保存好，放在web server下测试下。输入用户名和密码，提交后，到数据库中看下：

mysql> select * from users;
+——–+————————————————————–+
| user   |pass                                                         |
+——–+————————————————————–+
| myuser | $3b$08$Lg5XF1Tr.X5TGyfb43vBBeEFZm4GTRQhKQ6SY6emkcnhAGT8KfxFS |
+——–+————————————————————–+
1 row in set (0.00 sec)

至此，用户插入成功。

用户已经存在

下面，我们用上面的方法插入一个相同的用户，同时，用相同的密码。然后查看数据库：

mysql> select * from users;
+——–+————————————————————–+
| user   |pass                                                         |
+——–+————————————————————–+
| myuser | $3b$08$Lg5XF1Tr.X5TGyfb43vBBeEFZm4GTRQhKQ6SY6emkcnhAGT8KfxFS |
| myuser | $1a$08$7lM07FwQMm5/C8G/urT4z..MudfsS227e8oUEu6T51bNWk/RGb/qe |
+——–+————————————————————–+
2 rows in set (0.00 sec)

我们得到了用户名相同的两条记录，但是密码hash值不相同，虽然我们使用了相同的密码。

为了解决这个问题，我们可以在执行插入前先执行一个select语句，查询下该用户名是否已经存在了。但是，这对程序的效率来说不是最优化的。好的做法是让为用户名建立唯一索引，禁止用户用户名的出现：

DROP TABLE users;
CREATE TABLE users (user varchar(60), pass varchar(60), UNIQUE (user));

当我们插入相同的用户名时，程序就会报错：

An error occurred (MySQL execute: Duplicate entry ‘myuser’ for key 1).

如此，系统效率会得到提高。虽然，这是纯技术性的错误提示， 我们将稍侯予以解决。

避免泄漏过多服务器细节

上面出现的报错多是mysql服务器报错，可能会泄漏一些敏感信息，如数据库名，数据库地址，甚至数据表文件的存储地址都会被显示，这是很危险的。因此，这些信息我们并不希望被显示，除非我们就是用户，或者是在调试。如此，我们可以修改fail()函数，把错误信息显示为用户可见的内容。

// 是否为debug模式，如果是，会显示敏感信息。
$debug = TRUE;
 
function fail($pub, $pvt = '')
{
    global $debug;
    $msg = $pub;
    if ($debug && $pvt !== '')
        $msg .= ": $pvt";
/* $pvt 可能会含有敏感信息，比如需要隐藏掉，或者需要编码才能被html正确显示的内容。*/
    exit("An error occurred ($msg).\n");
}

需要注意的，不管是apache还是php，默认情况下是会显示所有调试信息的。所以，作为一个程序员，我们的职责是防止这些信息被泄漏，就跟我们设置了debug模式一样，这对程序员或者服务器运维人员来说至关重要。默认情况下，要把$debug值设置为false，但我们的例子作为测试来说，将继续使用true.

如何区分mysql报错

我们需要去辨别mysql报错，以确定用户是否已经存在于数据库中，如果已经存在，需要输出一个友好的错误提示。因为当我们插入用户的时候，不只是会有一种错误，当出现其它错误的时候，我们不能傻不愣瞪的提示相同的错误（用户已经存在）吧？

一种解决方法是在出现报错后执行一个针对该用户名的select查询，如果能够返回一行数据，说明用户确实一定存在了。实现方法如下：

if (!$stmt->execute()) {
    $save_error = $db->error;
    $stmt->close();
 
// 用户已经存在了?
    ($stmt = $db->prepare('select user from users where user=?'))
        || fail('MySQL prepare', $db->error);
    $stmt->bind_param('s', $user)
        || fail('MySQL bind_param', $db->error);
    $stmt->execute()
        || fail('MySQL execute', $db->error);
    $stmt->store_result()
        || fail('MySQL store_result', $db->error);
 
    if ($stmt->num_rows === 1)
        fail('This username is already taken');
    else
        fail('MySQL execute', $save_error);
}

这个方法确实奏效，而且也很可靠。但是，我们还有更简捷的实现方法，那就是使用mysql错误码：

if (!$stmt->execute()) {
    if ($db->errno === 1062 /* ER_DUP_ENTRY */)
        fail('额滴神，该用户已经存在了');
    else
        fail('MySQL execute', $db->error);
}

在接下来的例子中，我们将使用这种简单的方法做演示。

魔法引号的处理

Magic quotes 开启后会自动转义输入的数据。其中，所有的单引号（’）、双引号（”）、反斜线、和 NULL 字符都会被转义（增加个反斜线），其实这操作本质上调用的是 addslashes 函数。

这对程序员来说固然是一个很好的事情，省却了我们过滤的麻烦。但是，当用户输入用户名和密码中含有这些字符时，我们从$_POST中获取到的内容是不是也会被addslashes了呢？

这就需要我们去做判断，示例如下：

function get_post_var($var)
{
    $val = $_POST[$var];
    if (get_magic_quotes_gpc())
        $val = stripslashes($val);
    return $val;
}

接下来，我们将用这个函数取post过来的数据，而不是单纯的$_POST数组。 

(待续)

其实，最近的文章已经开始推荐使用phpass, 这是一个基于php的密码hash算法框架，已经被许多知名的web程序使用，如wordpress、Durpal 7等，但是目前并没有一篇详尽的，一步一步指引我们引用phpass的成型文章，而且密码安全问题，并不只是单纯的如何去hash密码予以存储的问题。

接下来，我将一步步介绍如何把用户密码管理方案引入到一套新的php程序中。首先，将简单阐述密码hash的概念以及如何安全地把这些密码送入数据库，然后通过个示例。从一个简单的创建新用户的程序开始，慢慢展开来，逐渐引入用户登录、修改（重置）密码的功能。

当然，文中会涉及其它相关的概念，如果你已了解，可直接略过。

密码HASH

合格的系统存储在数据库中的并不是密码明文，而是密码hash值。而实际上，单纯的把密码采用php函数，如md5,sha1等，加密后存储，会引发很严重的后果。只要正确的进行了hash，攻击者就很难从获取到的hash值中解析出用户密码，你只需要快速的把弱口令密码解决掉，就能把损失降到最低了。

当用户输入用户名和之前设定好的密码，点击登录进行验证后，程序先要根据用户名查询一些额外信息，如密码哈希类型，salt值，哈希重复的次数等，然后根据这些信息算出密码hash值，与已经存储的hash值进行比较，如果相同，则验证成功。

Salt方法

Salt是一个近乎随机的字符串，相同的密码使用不同的salt hash散列后， 会得到不同的结果，正确的使用这个方法，可以防止一系列的攻击，包括：

1.通过弱口令（如123456）就知道你的hash类型。

2.使用已经算好的hash值去做比对，如cmd5.com。

3.能够准确知道两个用户（或者一个用户的两个帐号）的密码是否是一样的。

Salt通常和密码hash值储存在一起，它并不是保密的。具体案例可参考Ucenter

算法强度要提升

一旦密码hash值泄漏 ，攻击者必然会采取暴力破解，一般的hash算法，如md5, sha1等，都是为了保证速度，而非为密码加密准备的，这样势必为攻击者缩短暴力破解提供了可能。因此，采取一个略微复杂点的hash算法，能够降低损失。假想下，如果你的每个密码生成时间家长0.2ms，用户不会有任何不好的体验，但对攻击者来说，这意味着什么？他要多付出几个月甚至几年的时间去破解你的密码！

关于phpass

Phpass是基于php的简单易用的密码hash算法框架。它提供三种hash方法，包括两种基于函数crypt()的—-CRYPT_BLOWFISH 和 CRYPT_EXT_DES，一种phpass自己的类md5的算法，前者只有php5.30以上的版本支持，后者这是全版本皆可。虽然，所有的算法都使用了salt及算法强度提升的方法，但考虑到效果，我们推荐使用前两种。在使用时，用户可以自定义hash迭代的次数。

在使用的时候，phpass能够自动生成salt和对进行算法拓展，你不需要为生成这些而费神。另外，phpass支持windows系统。

安全的接入数据库

SQL注入

所谓SQL注入，就是通过把SQL命令（特殊字符串，如单引号等）插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令的行为，比如先前的很多会员网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的，这类表单特别容易受到SQL注入式攻击．

如何防止SQL注入

　　1.永远不要信任用户的输入。对用户的输入进行转码校验，可以通过正则表达式，或限制长度；对单引号等特殊字符进行转换，如对数据进行url_encode\ stripslashes等。

　　2.永远不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取。

　　3.永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。（下面有详细说明）

　　4.不要把机密信息直接存放，加密或者hash掉密码和敏感的信息。

　　5.应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装。

在接下来的例子中 ，如上几点将得以体现。

组建数据库预备语句

目前，php提供三种连接mysql的接口，一种是自带的，被广泛应用的mysql扩展，另外一种是mysqli扩展， 还有一个PDO(PHP Data Objects)接口，只有mysqli和PDO支持MySQL的预备语句，而且都需要php5+的支持。本文使用mysqli的方式。

预备语句的使用使数据和代码分离，虽然这并不是最完美的防止sql注入的方法，以为从头到尾，所有的数据都使用相同的socket连接传输，但比传统的语句过滤使用起来更加简单，并且不容易出错。

对数据库采用最小权限原则

除了要预防SQL注入，我们还要预防其它各方面潜在的威胁。好的做法是使用最低权限的数据库帐号，也就是说，不要使用管理员权限的数据库链接，而是为每个应用使用单独的权限的数据库连接。这样，即使你的php代码并不是很“完美”，也可以把网站被攻破而付出最小的代价。

(待续)

如希望查找title中含有字母s的所有新闻：　　

select * from test.news where title like '%s%'

返回的结果中有一些包含s，而有些则只有中文，很郁闷（也很邪恶，嘿嘿）。

测试了下，发现一种解决方法，就是使用 BINARY（是CAST(str AS BINARY)简短写法) 强制转换进行检索

select * from test.news where binary title like '%s%'

这样结果就比较准确了，但还有一个问题，就是字母区分大小写，检索的时候依然不正确，只好再转化一下了：

select * from test.news where binary ucase(title) like  '%s%'

如此，临时解决办法搞定，不过速度会变慢，希望以后的mysql版本能解决掉此问题。

在oracle和mysql中，tablespaces用来存储一些诸如表和索引的数据段，而在postgres中,一个tablespac是一个物理单元，是一个连接到特定目录的符号连接，它不能运行在不支持符号连接的操作系统，如windows.

实际上，数据文件是oracle和mysql的物理存储机制，虽然postgres也把表数据存在独立文件中，但它支持的表空间非常小。因此，更加合理的把数据分发到磁盘上能够使oracle和mysql的性能更上一层楼, tablespaces正是为了这种合理分发数据方法便于操作而诞生的。

Oracle和mysql创建tablespace的语法基本相同，oracle支持更多的参数，且在一个tablespace允许由多个数据文件组成。下面是一个在mysql下创建和使用tablespace的简单示例：

mysql> create tablespace myts
-> add datafile 'myfirstfile'
-> engine = falcon;
Query OK, 0 rows affected (0.48 sec)
mysql> create table testmyts (
-> abc integer )
-> tablespace myts;
Query OK, 0 rows affected (0.11 sec)

简单说明下，第一条命令是创建一个名字为myts的tablespace, 赋给它的文件名字为myfirstfile，当然我们要使用falcon引擎(介绍)，运行完这个命令后，就会在mysql数据存储目录中发现一个名为myfirstfile的文件。

第二条命令是用这个tablespace创建一个表，这时候你再看那个tablespace文件，是不是变大了呢？如果没有，向这个表中多插入几条数据再看看。

在oracle中创建表结构，和mysql类似，也很简单：

SQL> create tablespace myts
 datafile 'myfirstfile'
 size 10M;
Tablespace created.
SQL> create table testmyts (
 abc integer )
 tablespace myts;
Table created.
SQL> 

在oracle中，我们无需声明引擎类型，但要声明存储大小。我们可以创建一个小体积的存储空间，然后使用autoextend让其自动扩展，但是这个存储大小是必须要初始化的。

首先向mysqld server 发送kill命令关掉mysqld server(不要用kill -9),存放进程ID的文件通常在MYSQL的数据库所在的目录/var/lib/mysql中，也可以用ps查看。

# killall -TERM mysqld

然后使用–skip-grant-tables参数来启动 mysqld。

# /usr/bin/safe_mysqld --skip-grant-tables

路径可以用locate找一下。

然后就可以无密码登录到mysqld server ，此时Mysql的密码和刚安装时一样，都是为空。现在我们可以使用mysqladmin来改变mysql的密码了。

#mysqladmin -u root -p password newpassword

最后记得要刷新权限表：

# mysqladmin flush-privileges

3NF 要求所有的属性都直接依赖于 primary key。3NF 和 2NF 最大的不同之处是，2NF 有依赖传递性,而 3NF 不准许。

例如,有一个符合 2NF 的表：

错误方式：

+———————+———–+—————-+———–+———-+——————

..some属性s | 用户号 | 用户发表文章数 | 用户登录数| 用户积分 | other 列 …

+———————+———–+—————-+———–+—————————–

…… | ID_001 | 4 | 20 | 13 | ……

+———————+———–+—————-+———–+———-+——————

用户积分规则：用户发表文章数 x 2 + 用户登录数 /4

在 3NF 中是不符合的。因为‘用户积分’是通过‘用户发表文章数’和‘用户登录数’，用公式计算得来的。也就是说，‘用户积分’依赖于‘用户发表文章数’和‘用户登录数’。

3NF 符合的划分方式是：

正确方式：

+———————+———–+—————-+———–+——————-

..some属性s | 用户号 | 用户发表文章数 | 用户登录数| other 列 …

+———————+———–+—————-+———–+——————-

…… | ID_001 | 4 | 20 | ……

+———————+———–+—————-+———–+——————-

正确方式：

+———————+———–+———–+——————–

..some属性s | 用户号 | 用户积分 | other 列 …

+———————+———–+———–+——————–

…… | ID_001 | 13 | ……

+———————+———–+———–+——————–

用户积分规则不变

需要注意的是，虽然 3NF 更加清楚地将用户资料和用户积分这两个关系表示了出来。但是在需要联合查询用户资料和积分的情况下，在大多数 RDBMS 如 MySQL 中，会造成性能消耗严重的情况。进一步讨论在 1.4 中进行。

1.3.1] Joining 关系

关系之间相互关联的方式有两种：INNER　JOIN 和 OUTER JOIN

INNER JOIN 查询会返回两个关系完全匹配的情况，MYSQL 默认的匹配方式为 INNER JOIN 。

如果你希望查询的结果即使没有匹配也会被查询出来，那么就要使用 OUTER JOIN 的连接方式。OUTER JOIN 又细分为三种：LEFT OUTER JOIN, RIGHT OUTER JOIN 和 FULL OUTER JOIN 。

LEFT　OUTER JOIN 是将左边的查询关系作为主关系，如果右面的关系有相匹配的 tuple , 那么处理方式和 INNER JOIN 一样；如果右面的关系没有与左边的关系相匹配，那么属性就会列出一个 NULL 的值。

RIGHT OUTER JOIN 的处理方式与 LEFT OUTER JOIN 类似，只不过是以右面的关系为主 关系。

FULL OUTER JOIN 与 INNER JOIN 的显示结果相同。

1.3.2] BCNF

修正的第三范式(BCNF) 全称 Boyce-Codd normal form 。是 3NF 的一个拓展，所以 BCNF 的前提和 3NF 是一样的：关系 必须符合 2NF ，并且有 KEY 可以用来相互关联。并不是所有符合 2NF 的关系都可以划分为 BCNF。

BCNF 简单来说，就是所有的 tuple 都依赖于 candidate key 或者这个 tuple 是 superkey 。因此所有的 tuple 都依赖于 key，从而避免了传递依赖问题。

1.4] NF 设计与性能消耗

NF 理论在设计之初，主要是为了应付数据冗余与存储重复而出的。当越来越庞大的数据库应用出现时，高度设计的 NF 带来的好处与性能所带来的坏处相互抵消了。因为通常，越高层次的 NF 会划分越多的 关系，从而查询出所需要的数据就需要更多的 join 操作。虽然 view 在一定程度上可以解决这个问题，但是视图本身也是一个不小的性能消耗。

如果一个 MySQL 执行的多是 SQL-Transaction 的话，那么使用高层次的 NF 设计就显得尤为必要，因为书写 transaction 的 SQL 语言通常都不适于做复杂的过程处理，而高层次的 NF 设计可以在逻辑上更清楚的划分关系，从而较少的操作关系之间的关系处理，较多的操作关系之间的数据。

而如果一个 MySQL 在应用中 ，更多的是扮演数据存储与统计的操作，那么高层次的 NF 设计就没有必要。因为此类应用中，通常都搭配使用高级编程语言，而高级编程语言灵活多样，在逻辑、过程与数据的处理过程中，都要比 SQL 更加的强壮。

1.5] NF 与 SQL 的关系

SQL 语言是为了结构化的查询数据而发明的一种机器查询语言。主要的功能是查询，兼顾数据定义与控制的功能。

SQL 大致可以分为三类：

1.5.1] Data Manipulation Language (DML)

DML 主要用来 查/删/改/插关系的 tuple 。他们共同的特点是都需要指定作用的关系和关系之间的关系。

1.5.1.1] Select

Select 用来查询关系中的 tuple 包括:

Select : 后面跟属性,作用是控制查询的输出。

From : 后面跟关系与 joins ,作用是控制与关联关系之间的关系。

Where : 后面跟属性的限制语句，主要是用来划分查询的区域。

Group By : 后面跟属性,主要用来将相似的属性分成单一的结果集。

Having : 与 Where 作用相同，作用域为 Group By 控制的结果集。

Order By: 用来将最后筛选出来的结果集，通过某一 tuple 来进行排序。

具体作用详见：1.2.1]

1.5.1.2] Insert

Insert 用来插入 tuple。具体作用详见：1.2.2]

1.5.1.3] Update

Update 用来更新 tuple 。具体作用详见：1.2.3]

1.5.1.4] Delete

Delete 用来删除 tuple 。作用域与 Select 类似，但是不返回查询的 tuple。

1.5.2] Data Definition Language (DDL)

DDL 的作用是创建关系与定义关系中的属性。主要包括三大部分：

1.5.2.1] CREATE

创建语句,可以用来创建 Database、关系、transaction(祥见 1.2.4) 等。根据需要创建的类型不同，语句稍有差别。

1.5.2.2] DROP

删除语句，与 CREATE 语句相反。

1.5.2.3] ALTER

修改关系和 Transaction 。

1.5.3] Data Control Language (DCL)

DCL 的作用是用来控制关系和属性的权限。主要有两部分：

1.5.3.1] GRANT

用来创建访问关系与属性的权限

1.5.3.2] REVOKE

用来删除访问关系与属性的权限

原文作者：韩述 杜工稍作修改。

术语：通常在具体的 RDBMS 如 MySQL 的应用开发中，将一个关系叫做表，一条元组（tuple） 称为行，一个属性叫做列。 因为范式（NF） 设计主要是讲理论，所以在本文中，一律将表称为关系，将行称为tuple，将列称为属性。

如图：

1.1] First Normal Form(1NF)

1NF(第一范式) 的目的是将数据拆分成原子状态。例如 一个大型文章发布系统的文章序列号的组成是 8 位用户名 + 该用户所属的文章号，如某用户的用户名是 ID_001 ，他发表的某一篇文章，在他的文章列表中的序列号是 15 ，这篇文章在该系统中唯一序列号是 ID_00115 。

将文章序列号存储到关系中去，通常的做法是这样的：

错误的方式

+———————-+—————–+—————+

some属性…… | 文章序列号 | other 列……

———————-+—————–+—————-

……| ID_00115 |

这么做是不符合 1NF 规范的。因为文章序列号是两部分组成的，如果存成一个属性那么就违反了 1NF 的原子性原则。

符合 1NF 的属性划分方法如下：

正确方式：

+———————-+————–+——–+—————+

some属性…… | 用户号 | 文章号 | other 列……

———————-+—————+——–+—————-

……| ID_001 | 15 |

+———————-+————-+——–+—————+

1.2] Second Normal Form（2NF）

2NF 划分关系的原则是：一个关系中的所有非 Key属性s 必须完全的依赖于 Key。如果是多主键的话，那么非主键属性s 必须完全依赖所有的主键.

1NF 的范围是同一关系的不同属性之间的划分。而 2NF(第二范式) 的范围是将一个大的，数据相互重叠与冗余的关系拆分成众多小的，关系 ，他们之间相互的联系就是 Key ，Key 是一个关系中唯一标示一个tuple 的标识。而且在 2NF 中，所有有效的单一的 Key 默认都是 Primary key。(多个 Key 唯一定位一个tuple ,那么这些Key 称为复合主键) 。

另外一点需要特别注意的是，范式是属性递增的，因此，只有在完成了 1NF 之后，才能进行 2NF 的划分。

例如某文章系统中，一个存储某一篇文章的关系，有如下字段

错误方式：

+————————–+————+———-+———–+———–+————–+—————-+———–+——————

..some属性s | 用户号 | 文章号 | 文章标题 | 文章内容 | 文章创建时间 | 用户发表文章数 | 用户登录数| other 列 …

+————————–+————+———-+———–+———–+————–+—————-+———–+——————

……| ID_001 | 15 | Article | Cnt … | 1223372589 | 4 | 20 | ……

其中，‘用户号’和‘文章号’对于 ‘文章标题’、‘文章内容’、‘文章创建时间’来说，可以算是复合主键，因为要查出这些属性，必须完全依赖 ‘文章号’和 ‘用户号’这两个属性，缺一不可。

而 ‘用户发表文章数’和 ‘用户登录数’这两个属性仅依靠 ‘用户号’就可以出来，所以 ‘用户号’是 ‘用户发表文章数’和 ‘用户登录数’的主键，而 ‘文章号’则和这两个属性没有关系。也可以说 ‘用户发表文章数’和 ‘用户登录数’没有完全依赖于复合主键，所以这个表不符合 2NF 标准(但是所有属性都是原子不可分状态，因此这个表符合 1NF 标准)。

如果要符合 2NF 标准，就需要将这个关系拆分成两个关系

正确方式：

+————————–+————+———-+———–+———–+————–+————————–

..some属性s | 用户号 | 文章号 | 文章标题 | 文章内容 | 文章创建时间 | other 列 …

+————————–+————+———-+———–+———–+————–+————————–

……| ID_001 | 15 | Article | Cnt … | 1223372589 | ……

+————————–+————+———-+———–+———–+————–+—————————

正确方式：

+————————–+————+—————–+———–+——————-

..some属性s | 用户号 | 用户发表文章数 | 用户登录数| other 列 …

+————————–+————+—————–+———–+——————-

……| ID_001 | 4 | 20 | ……

+————————–+————+—————–+———–+——————-

这样，Right way one . 中剔出了不符合完全依赖的两个属性s ，所有的属性s 都完全依赖 composite primary key ，可以认为 Right way one. 符合 2NF 标准。

另外，将 Wrong way. 中剔出的两个属性s 划分到了 Right way two. 里面，primary key 是 ‘用户号’。因此 Right way two. 仅就一个 primary key ，并且所有内容都依赖于 primary key 查询，所以可以说 Right way two. 符合 2NF 的要求。

1.2.1] 关系模式

经过 2NF 的拆分，现在关系的数量在增加，但是属性之间的关系趋向于更加的简单明了。

关系之间根据对应联系的不同，有三种不同的关系模式：

· 一对一

· 一对多

· 多对多

·一对一 ， 既一个属性仅可以对应一个其他的属性

例如：一个用户号和用户之间就是一对一的关系，一个用户只能有一个用户号，一个用户号只能指定某一个用户。

·一对多 ， 既一个属性可以对应多个其他的属性

例如: 一个用户号可以对应多个文章号,因为用户可以发表多篇的文章.

·多对多 ， 既多个属性可以对应多个其他的属性

完全多对多就是 Cartesian product(笛卡尔积或直积)。

例如: 一个用户可以发相同标题的不同文章。而拥有相同标题的文章，可以由不同的用户发。