员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：
(仓库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范式的，消除了删除异常、插入异常和更新异常。
范式应用
我们来逐步搞定一个论坛的数据库，有如下信息：
（1） 用户：用户名，email，主页，电话，联系地址
（2） 帖子：发帖标题，发帖内容，回复标题，回复内容
第一次我们将
数据库设计为仅仅存在表：
用户名 email 主页 电话 联系地址 发帖标题 发帖内容 回复标题 回复内容
这个数据库表符合第一范式，但是没有任何一组候选关键字能决定数据库表的整行，唯一的关键字段用户名也不能完全决定整个元组。我们需要增加"发帖ID"、"回复ID"字段，即将表修改为：
用户名 email 主页 电话 联系地址 发帖ID 发帖标题 发帖内容 回复ID 回复标题 回复内容
这样数据表中的关键字(用户名，发帖ID，回复ID)能决定整行：
(用户名,发帖ID,回复ID) →(email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容)
但是，这样的设计不符合第二范式，因为存在如下决定关系：
(用户名) →(email,主页,电话,联系地址)
(发帖ID) →(发帖标题,发帖内容)
(回复ID) →(回复标题,回复内容)
即非关键字段部分函数依赖于候选关键字段，很明显，这个设计会导致大量的数据冗余和操作异常。
我们将数据库表分解为（带下划线的为关键字）：
（1） 用户信息：用户名，email，主页，电话，联系地址
（2） 帖子信息：发帖ID，标题，内容
（3） 回复信息：回复ID，标题，内容
（4） 发贴：用户名，发帖ID
（5） 回复：发帖ID，回复ID
这样的设计是满足第1、2、3范式和BCNF范式要求的，但是这样的设计是不是最好的呢？
不一定。
观察可知，第4项"发帖"中的"用户名"和"发帖ID"之间是1：N的关系，因此我们可以把"发帖"合并到第2项的"帖子信息"中；第5项"回复"中的"发帖ID"和"回复ID"之间也是1：N的关系，因此我们可以把"回复"合并到第3项的"回复信息"中。这样可以一定量地减少数据冗余，新的设计为：
（1） 用户信息：用户名，email，主页，电话，联系地址
（2） 帖子信息：用户名，发帖ID，标题，内容
（3） 回复信息：发帖ID，回复ID，标题，内容
数据库表1显然满足所有范式的要求；
数据库表2中存在非关键字段"标题"、"内容"对关键字段"发帖ID"的部分函数依赖，即不满足第二范式的要求，但是这一设计并不会导致数据冗余和操作异常；
数据库表3中也存在非关键字段"标题"、"内容"对关键字段"回复ID"的部分函数依赖，也不满足第二范式的要求，但是与数据库表2相似，这一设计也不会导致数据冗余和操作异常。
由此可以看出，并不一定要强行满足范式的要求，对于1：N关系，当1的一边合并到N的那边后，N的那边就不再满足第二范式了，但是这种设计反而比较好！
对于M：N的关系，不能将M一边或N一边合并到另一边去，这样会导致不符合范式要求，同时导致操作异常和数据冗余。
对于1：1的关系，我们可以将左边的1或者右边的1合并到另一边去，设计导致不符合范式要求，但是并不会导致操作异常和数据冗余。
结论
满足范式要求的数据库设计是结构清晰的，同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的，在数据库表中存在1：1或1：N关系这种较特殊的情况下，合并导致的不符合范式要求反而是合理的。
在我们设计数据库的时候，一定要时刻考虑范式的要求。
一、必要性
随着近年来数据库技术的深入发展，以Unix平台为代表的Informix Dynamic Server和以NT平台为代表的MS SQL Server得到了广泛的应用。在一个公共的环境中，存在大量的用户操作，有数据库管理员，主要做数据管理维护工作，也有普通用户，做一定授权下的数据修改和数据查询。我们知道，每个数据库服务器上可建立多个不同类别的数据库，而每个数据库中也可以生成多个存储过程、表、视图等。如何保证数据的安全可靠，防止非法存取所造成的破坏和数据泄露，如何进行权限的划分和设置，这是安全管理的重点，也是数据库可靠运行的保证。本文以Informix Dynamic Server为例做详细说明。
二、权限的划分
Informix Dynamic Server使用了三级权限来保证数据的安全性，它们分别是数据库级权限、表级权限和字段级权限，具体为：
1．数据库级权限
包括Connect、Resource、DBA三种类别，其中：
Connect：最低级，仅允许用户访问数据库中的表和索引，但不能创建和删除它们；
Resource: 建立在Connect之上，允许用户在数据库中创建、删除表和索引；
DBA：即数据库管理员，拥有数据库管理的全部权限，包括访问数据库表、创建和删除索引、修改表结构、授予数据库权限给其他用户等。
2．表/字段（视图）级权限
指允许进行何种具体操作，主要包括：
Select: 从表或字段中检索信息；
Update: 修改指定字段的值；
Insert: 向数据库表中添加记录；
Delete: 从数据库表中删除记录；
Index: 为一个数据库表创建索引；
Alter: 增加、删除数据库表中的字段，或修改字段的数据类型；
All: 以上所有权限。
三、权限的设置
Informix Dynamic Server通过一系列SQL控制语句来实施对用户权限的设置，使得不同的用户只能在各自限定的范围内存取数据。以下命令格式中Grant表示授予权限，Revoke表示撤消权限，User-List指用户名列表，多个用户以逗号（，）分隔，对大多数数据库
系统而言，PUBLIC代表所有用户。
1．对于数据库，其格式为：
Grant { DBA Resource Connect } to { PUBLIC User |