摘要：【目的】了解数据库中角色（Role）的概念和用处。【方法】用李老板的公司发展中碰到的问题例证角色的重要性【结论】角色在用户越多的情况下越能凸显出它的作用。
这样生产者登陆以后只能操作表1，供应者登陆以后只能操作表2...隔离效果非常好。但是，如果总经理想要查看一个产供销的综合报表该如何办呢？在这样的设计下，是根本做不到的。所以我们目前看到的实际情况是，基本上一个数据库只用一个架构和一个用户登陆。
3.1 深入了解架构(Schema)
在进入李老板的故事之前，让我们先对Sql Server2005中的架构做一个更深入的了解。
用户(User)和架构(Schema)的关系
- 一个架构有且只有一个所有者Owner。
- 一个用户可以拥有多个架构。
这跟第二节中介绍的货架权限清单有所出入，第二节中的例子是多对多的关系，而实际Sql Server是采用一对多的关系。这反而比较像是银行账户。一个人可以有多个存折，但是一个存折只有一个用户。
- 创建一个用户，系统将自动创建一个同名的架构。
- 创建一个架构必须指定所有者，否则将默认为当前登陆用户。
- 表属于不同的架构也不能重名。
- 删除一个用户时，架构也会被删除？
架构(Schema)相关的SQL
创建架构
CREATE SCHEMA [SchemaName] AUTHORIZATION [User]
更改架构的所有者
删除架构
数据库设计与架构
架构的目的应该在于在同一数据库中提供一种隔离机制。按照这种思路，以最典型的产供销结构，我们可以这样设计一个数据库MyDatabase：
| 用户 | 架构 | 表 | 表全称 |
| 生产者 | 生产 | 表1 | 生产.表1 |
| 供应者 | 供应 | 表2 | 供应.表2 |
| 销售者 | 销售 | 表3 | 销售.表3 |
| 用户 | 架构 | 表 | 表全称 |
| MyUser | MySchema | 表1 | MySchema.表1 |
| 表2 | MySchema.表2 | ||
| 表3 | MySchema.表3 |
这下总经理要看报表是没问题了，但是这样架构就形同虚设了。这也是为什么大家搞不清楚架构和用户的关系的原因。假如一个架构可以有多个拥有者，那么就可以彻底解决这个问题。
有人要说了，但是好像我用dbo登陆以后，是可以操作不同架构的表啊，这是为什么呢？那是因为上面的讨论是建立在没有角色的基础上的，要说清楚角色的问题，我们还是要回到李老板的故事。
3.2 人多不好管
1.大量的重复
2.工作调动
3.3 所有权与经营权
3.4 DB Role与App Role
3.5 数据库设计与角色
