SQL SERVER 2005中的Schema详解
2009-03-05 23:38 K-imba 阅读(569) 评论(0) 编辑 收藏 举报以往 SQL Server 内的对象命名是“服务器.数据库.用户名.对象”,但新版的对象命名改为“服务器.数据库.Schema.对象”。这让你规划数据库对象命名时更有弹性。
架构是形成单个命名空间的数据库实体的集合。命名空间是一个集合,其中每个元素的名称都是唯一的。
虽然 SQL Server 2000 包含 CREATE SCHEMA 语句,但实际上并不会像上面所定义的那样创建架构。在 SQL Server 2000 中,数据库用户和架构是隐式连接在一起的。每个数据库用户都是与该用户同名的架构的所有者。对象的所有者在功能上与包含它的架构所有者相同。因而,SQL Server 2000 中的完全限定名称的“架构”也是数据库中的用户。因此,从 SQL Server 2000 数据库中删除用户之前,管理员需要删除该用户所拥有的所有对象或更改这些对象的所有者。以包含此对象的 SQL Server 2000 数据库为例:
accounting.ap.george.reconciliation
此对象的所有者为用户“george”。如果管理员需要删除用户“george”,则必须先删除此对象或更改此对象的所有者。在后一种情况下,可以按如下方式将其重命名:
accounting.ap.sandra.reconciliation
转让对象的所有权也会更改其完全限定名称。引用 accounting.ap.george.reconciliation 的任何代码必须经过更新以反映对名称所做的更改。
在 SQL Server 2005 中,架构独立于创建它们的数据库用户而存在。可以在不更改架构名称的情况下转让架构的所有权。并且可以在架构中创建具有用户友好名称的对象,明确指示对象的功能。例如,除了 accounting.ap.sandra.reconciliation 外,您还可以创建名为 accounting.ap.invoice.reconciliation 的架构。因为“invoice”不是用户,所以从数据库中删除用户后,无需更改此名称。这就简化了数据库管理员和开发人员的工作。
用户架构分离的好处
将架构与数据库用户分离对管理员和开发人员而言有下列好处:
多个用户可以通过角色成员身份或 Windows 组成员身份拥有一个架构。这扩展了允许角色和组拥有对象的用户熟悉的功能。
极大地简化了删除数据库用户的操作。
删除数据库用户不需要重命名该用户架构所包含的对象。因而,在删除创建架构所含对象的用户后,不再需要修改和测试显式引用这些对象的应用程序。
多个用户可以共享一个默认架构以进行统一名称解析。
开发人员通过共享默认架构可以将共享对象存储在为特定应用程序专门创建的架构中,而不是 DBO 架构中。
可以用比早期版本中的粒度更大的粒度管理架构和架构包含的对象的权限。
完全限定的对象名称现在包含四部分:server.database.schema.object。
用户与架构(schema)分开,让数据库内各对象不再绑在某个用户账号上,可以解决之前版本“用户离开公司"问题,也就是在拥有该对象的用户离开公司,或离开该职务时,不必要大费周章地更改该用户所有的对象属于新的用户所有。另外,也可让 DBA 在安装某个套装软件时,设置该套装软件所用的数据库对象都属于某个特定的架构,容易区别。也就是说,在单一数据库内,不同部门或目的的对象,可以通过架构区分不同的对象命名原则与权限。
默认架构
SQL Server 2005 还引入了“默认架构”的概念,用于解析未使用其完全限定名称引用的对象的名称。在 SQL Server 2000 中,首先检查的是调用数据库用户所拥有的架构,然后是 DBO 拥有的架构。在 SQL Server 2005 中,每个用户都有一个默认架构,用于指定服务器在解析对象的名称时将要搜索的第一个架构。可以使用 CREATE USER 和 ALTER USER 的 DEFAULT_SCHEMA 选项设置和更改默认架构。如果未定义 DEFAULT_SCHEMA,则数据库用户将把 DBO 作为其默认架构(如果创建表时没有给定架构,则分配dbo)。
SQL Server 2005 Database Engine 管理着可以通过权限进行保护的实体的分层集合。这些实体称为“安全对象”。在安全对象中,最突出的是服务器和数据库,但可以在更细的级别上设置离散权限。SQL Server 通过验证主体是否已获得适当的权限来控制主体对安全对象执行的操作。
附:
图一 安全对象与架构关系
图二 数据库引擎权限层次结构之间的关系图