数据库中Schema、Database、User、Table的关系[转]

数据库的初学者往往会对关系型数据库模式（schema）、数据库（database）、表（table）、用户（user）之间感到迷惘，总感觉他们的关系千丝万缕，但又不知道他们的联系和区别在哪里，对一些问题往往说不出个所以然来。下面，我们就以SQL Server为核心，对其模式（schema）、数据库（database）、表（table）、用户（user）之间的关系展开讨论。

首先，我们先弄清楚什么是模式。

先明确一点，SQL Server中模式（schema）这个概念是在2005的版本里才提出来的，因此SQL Server2000不支持模式这个概念（本人曾在此处吃过亏）。

模式又称架构，架构的定义是形成单个命名空间的数据库实体的集合。命名空间是一个集合，其中每个元素的名称都是唯一的。在这里，我们可以将架构看成一个存放数据库中对象的一个容器。

上面的文字描述过于晦涩，举个简单的例子，平时要在电脑硬盘存放东西时，我们不会把所有的东西都存在一个文件夹里，而是会把不同的文件按照某一个标准分门别类，放到不同的文件夹里。而在数据库中，起到这个作用的就是架构，数据库对象（表、视图、存储过程，触发器等）按照一定的标准，存放在不同的架构里。有过java编程经验的同学都知道，命名空间名其实就是文件夹名，因此我们非常明确一点：一个对象只能属于一个架构，就像一个文件只能存放于一个文件夹中一样。与文件夹不同的是，架构是不能嵌套的，如此而已。因此，架构的好处非常明显——便于管理。

那么，现在我们来看看用户和模式（schema，即架构）有什么关系。

通过上面的分析，我们知道，一个架构可以容纳多个数据库对象，但并不是所有的用户都能访问某一个架构里的内容的，这就是所谓的权限。看下面一张表：

	User1	User2	User3	User4
Schema1	Y	Y	N	N
Schema2	N	Y	N	Y
Schema3	Y	N	Y	N

 

通过这张表，我们可以看出，用户1可以访问架构1和架构3，用户2可以访问架构1和架构2，以此类推。

在sql server2000中，用户和架构是不分离的，到了2005才分离。其实2000中的用户和架构概念就是为用户分配固定的模式，即如下表：

	User1	User2	User3
Schema1	Y	—	—
Schema2	—	Y	—
Schema3	—	—	Y

综合上面所述，用户和构架的关系是多对多的——一个架构可以对应多个用户，一个用户也可以对应多个架构。

现在，我们来讨论一下，数据库（database）和模式（schema）有什么关系。

举个很浅显的例子，我们可以把数据库看作是一个大仓库，仓库分了很多很多的房间，Schema就是其中的房间，一个Schema代表一个房间，于是乎，在不同的房间里，我们可以放不同的东西——有的放食物，有的放衣物……而这些不同的东西，就对应着我们数据库里的对象。

因此，我们可以看到，数据库与模式时一对多的关系。

总结一下，其实我们的数据库就是一个数据的大仓库，而里面创建了很多很多模式，分别放着不同的数据库对象（包括表），而不同的模式有不同的权限，于是，不同的用户就有不同的访问权限来访问某个模式里的数据库对象。