人大金仓KingbaseES中的用户与模式概念及关联

KingbaseES中的用户与模式概念及关联
一、用户
在实际应用中，作为数据库管理员，必须确保需要访问的数据库的个人具有适当级别的权限，为了使用户能够创建和管理对象，DBA需要为用户授予适当的权限。

一旦某个用户创建了一些对象，该用户随之可以被授予操纵这些对象的权限，而DBA不需要涉及对单个用户所创建对象的管理权限。

要想访问数据库，任何人需要成为能够通过数据库身份认证的有效数据库用户，则可以配置应用程序要求每个需要进行访问的个体都具有不同的数据库账户，同时也可以配置应用程序自身作为公共用户连接数据库并在内部处理应用程序级别权限，无论哪一种方式，在数据库中内都需相应地创建一个或多个允许操纵数据的用户。

需要提到的是，在KingbaseES中，用户是实例级的，所以我们平时在KingbaseES中，虽在不同数据库下，查询系统表SYS_USER、SYS_DATABASE中看到关于用户的信息结果都是一致的，记录的是所有的用户、所有的数据库。

用户与数据库是一对多的关系。

无论当前连接在哪个数据库下，创建的用户都是实例级。

在KingbaseES中创建用户时，该用户默认有当前数据库的connect权限，当需要连接登录到其它用户创建数据库时，需要DBA将其它数据库的CONNECT权限赋予该用户才能正常登录，但该用户需要访问操作数据库下的其他用户所创建的对象时，同样需要被赋予相应的权限才可行。

另外，在KingbaseES中，用户拥有connect权限登录数据库后，默认情况下用户拥有PUBLIC模式CREATE 的权限（下文中会详细说明），即默认该用户可以在PUBLIC模式下创建属于自己的数据对象。

数据库管理系统为了方便各用户对数据对象的管理，如同在KingbaseES Help里提到的，在实际应用场景下，为了：
多个用户使用同一个数据库而不会相互影响。

对数据库中的对象进行逻辑分组，更便于管理。

各个应用分别使用各自的模式，以避免命名冲突。

而引入模式的概念。

二、模式
模式（SCHEMA）是一个逻辑数据结构概念，可以理解成是表，视图等一系列数据对象的集合。

也称为命名空间，不同模式下的数据库对象可以重名。

其类似于操作系统层次的目录，只不过模式不能嵌套。

Oracle
在Oracle中，每个数据库用户拥有一个与之同名的模式，所以在Oracle中，模式则可以理解成是某个用户拥有的所有对象的集合。

当Oracle的某一用户登录数据库，不指定模式时，默认是在该用户同名模式下的数据对象进行操作。

Oracle在创建数据库的同时会创建多个数据库用户，这些用户在默认情况下被锁定，只有SYS和SYSTEM两个用户始终会被创建且始终没有被锁定。

SYS用户拥有数据字典及其关联的所有数据对象，SYSTEM则可以访问数据库内的所有对象。

Kingbase
在KingbaseES中，在创建数据库时，会默认创建三个模式：PUBLIC、SYS_CATALOG、以及INFORMATION_SCHEMA。

PUBLIC：我们平时在使用KingbaseES时，经常会没有声明任何模式名字就创建了表。

其实这是在默认情况下，这样的表(以及其它对象)都自动放到一个叫做"PUBLIC"的模式
中去了。

可以看到在默认情况下，下面的语句是等效的：
CREATE TABLE products ( ... );
CREATE TABLE public.products ( ... );
从上面例子以及该模式的名字意思我们就能大致理解，PUBLIC是一个公共模式，在默认情况下，数据库中的每个用户都是可以在PUBLIC模式上有CREATE和USAGE权
限，在数据库中不指定明确指定模式而创建对象时，默认是在PUBLIC模式下创建。

另外，在默认情况下，用户是无法访问模式中不属于他们所拥有的对象的。

为了让他们能够访问，模式的所有者需要在模式上赋予他们USAGE权限。

为了让用户使用模
式中的对象，我们还可能需要赋予适合的该对象额外权限才可行。

同时，不用用户也可
以在别人的模式里创建对象。

但需要被赋予在该模式上的CREATE 权限。

INFORMATION_SCHEMA：可称为信息模式，在SQL 92标准中定义，主要包含有关当前数据库里定义的对象的信息，主要是由一系列视图组成，因为其中视图结构、数据
类型等都是标准定义，所以可以认为在不同数据库中都是可移植的，并且相对稳定。

它与系统表不一样，因为系统表是各RDBMS特有的，是在实现的基础上进行的建模。

所以我们经常可以看到一些数据库使用者，也许在接触一个新的关系数据库管理系统
产品时，可能对其系统表等的使用还不是很熟悉，但又想查一些系统数据的基本信息，所以可能就会考虑这个数据库系统是否定义了INFORMATION_SCHEMA？如果有，这样就能较快地到INFORMATION_SCHEMA中根据可利用的视图来获取信息。

在主流RDBMS中目前支持信息模式的包括MS SQL Server、PostgreSQL、MySQL、KingbaseES等，Oracle在这部分目前没有遵照标准定义提供INFORMATION_SCHEMA模
式。

注：缺省的时候，信息模式不在模式搜索路径中，因此，我们需要用全称来访问里面的所有对象。

SYS_CATALOG模式用于存放系统表和所有内置的数据类型、函数和操作符。

SYS_CATALOG总是搜索路径中的一部分。

如果它没有明确出现在路径中，那么它隐含地在所有路径之前搜索。

这样就保证了内置数据对象名字总是可以被搜索到。

模式的搜索路径(Search_path)
当用户在创建或使用数据库对象而没有指定模式时，为什么会默认在PUBLIC模式下创建？能否修改默认模式?答案是肯定的，就是上文中提到的“搜索路径”。

在KingbaseES中，系统是根据搜索路径（对应系统参数：search_path，会话级）来确定该对象所属的模式。

搜索路径包含一组模式列表，系统在使用数据对象时，会使用第一个搜索匹配的数据库对象。

如果在搜索路径中没有找到匹配的对象，系统将会报错。

例如系统存在名为SCHEMA1、SCHEMA2的模式，设置search_path= SCHEMA1, SCHEMA2,PUBLIC; 则搜索路径会依次在SCHEMA1、SCHEMA2、PUBLIC模式路径下进行搜索。

一旦搜索到第一个匹配的对象，就返回对象信息。

停止搜索。

search_path参数的默认值是：$user,public。

在设置时若不特别指定，所设参数值默认进行大写转换。

其含义是首先搜索与用户名相同的模式，如果该模式不存在，则使用PUBLIC模式。

因此，当用户没有自己的模式并且其创建或使用数据库对象没有指定模式时，会默认在PUBLIC模式下创建。

在KingbaseES 6.1.3以后的版本中，增加了compatible_level参数的一个取值：oracle，若设置compatible_level=’oracle’时，则在创建用户的同时，会在所连接的数据库中创建一个用户同名的模式，以兼容Oracle每个用户对应一个同名模式，并根据search_path的取值，默认首先在用户同名模式下搜索数据库对象。

所以就能实现我们之前的ORACLE用户习惯的用法，即，每个用
户对应自己的模式，同时我查询不指定模式名时，首先在我自己模式空间内查询我需要的数据库对象。

应列出典型的问题及其分析方法：
下面是几个常见问题：
创建表成功，但是查询时却说表不存在？
A：首先需确认所创建的表，是在当前数据库下哪个模式下创建的？然后查看当前的search_path参数值是否包含该模式路径。

若没有找到，则需将该路径设置加入search_path 中。

查询表结果不是期望的结果？
A：首先确认在当前数据库下，希望查询的表是哪个模式下的表，然后再指定该模式查询该表，看看是否还不是期望结果？查看search_path的值，确认是不是因为由于搜索路径的顺序不对，造成查询到其他模式下的表，例如前面提到的，设置search_path=SCHEMA1，
SCHEMA2，PUBLIC, 但此时想查找SCHEMA2下的table1没有指定模式：
Select * from table1；
若不指定模式，默认会首先的SCHEMA1下寻找，若SCHEMA1中存在table1，则返回SCHEMA1模式下的table1的数据，所以造成与期望返回不一致的情况。

不同模式下的同名表需要共存，怎么能保证访问正确？
A：在当前数据库下，访问数据对象时，需指定模式名，就可以避免造成混乱的情况。

例如上面的查询可以为：
SELECT * FROM SCHEMA2.TABLE1;
SELECT * FROM SCHEMA1.TABLE1
这样就可以确定所需要的表信息。

使用方式
模式可以用多种方式组织数据。

下面是一些使用模式建议，它们也很容易在缺省配置中得到支持：
如果没有创建任何模式，那么所有用户隐含都访问PUBLIC 模式。

这样就模拟了没有模式的时候的情景。

这种设置建议主要用在只有一个用户或者数据库里只有几个可信用户的情形。

这样的设置也允许我们平滑地从无模式的环境过渡。

可以为每个用户创建一个模式，名字和用户相同。

要记得缺省的搜索路径从$user 开始，它会解析为用户名。

因此，如果每个用户都有一个独立的模式，那么他们缺省时访问他们自己的模式（这种情况用于想要每个用户都有自己同名模式并默认使用，且并不想在其它数据库特性方面上兼容Oracle的情况下使用，否则只需设置compatible_level=’oracle’，就可以默认创建用户时，创建一个同名模式）。

如果使用了这样的设置，也许我们可能还想撤销对PUBLIC模式的访问(或者删除PUBLIC模式)，这样，用户就可真的限制于他们自己的模式了（之前提到的方法：REVOKE CREATE ON SCHEMA PUBLIC FROM PUBLIC）。

要安装共享的应用(被所有人使用的表、第三方提供的额外函数等等)，我们可以把它们放到独立的模式中。

只要记得给需要访问它们的用户赋予合适的权限就可以了。

然后用户就可以通过用一个模式名修饰来使用这些额外的对象，或者他们可以把额外的模式放到他们的搜索路径中。