ArcSDE用户介绍

原文：点击打开链接

今天给大家介绍一个关于ArcSDE用户的相关内容，我们以Oracle数据库为例。

数据库DBA用户
一提到Oracle数据库，想必大家肯定对Oracle的DBA用户都如雷贯耳，不管是SYS、SYSTEM，这些用户都是Oracle的超级用户，可以做很多其他用户不能做的事情，在ArcSDE的安装过程中也需要了解和使用该用户，因为需要使用SYS用户来创建SDE表空间、用户、赋予SDE的相关权限等，另外如果选择某些数据库备份方法的话，还需要使用DBA用户来备份数据库。另外一个很关键的问题，在我们进行ArcSDE的Post Intallation过程中，需要使用SYS用户赋予Public两个权限：

[html]  view plain  copy

 print ?

1. grant execute on dbms_pipe to public;  
2. grant execute on dbms_lock to public;  

ArcSDE管理员用户

下面就是SDE用户了，一般情况下，这个SDE用户的名称建议大家不要修改（这个名称修改会不会引起问题，我没有怎么测试过），SDE用户相当于ArcSDE数据库的超级管理员，该用户在创建SDE的Schema和升级SDE的Schema都扮演重要的角色。另外在进行ArcSDE版本压缩、ArcSDE的服务管理、ArcSDE参数修改等方面也只有SDE用户才能操作。

[html]  view plain  copy

 print ?

1. prompt * * * * * * * * * * *  
2. prompt * 创建SDE Schema的权限  *  
3. prompt * * * * * * * * * * *  
4.   
5. grant  CREATE SESSION to sde;  
6. grant  CREATE TABLE to sde;  
7. grant  CREATE PROCEDURE to sde;  
8. grant  CREATE SEQUENCE to sde;  
9. grant  CREATE TRIGGER to sde;  
10. grant  CREATE TYPE to sde;  
11. grant  CREATE LIBRARY to sde;  
12. grant  CREATE PUBLIC SYNONYM to sde;  
13. grant  CREATE OPERATOR to sde;  
14. grant  CREATE INDEXTYPE to sde;  
15. grant  DROP PUBLIC SYNONYM to sde;  
16. grant  CREATE VIEW to sde;  
17. prompt * UNLIMITED TABLESPACE is not required. Grant this privilege   
18. prompt * if you do not wish to explicitly manage and grant tablespace quota to SDE user.  
19. grant  UNLIMITED TABLESPACE to sde;  
20. //该权限在安装完毕后可以revoke  
21. grant  ADMINISTER DATABASE TRIGGER to sde;  
22.   
23.   
24. prompt * * * * * * * * * * *  
25. prompt * 升级SDE Schema的权限  *  
26. prompt * * * * * * * * * * *  
27.   
28. prompt * If upgrading please remove rem from each grant.  
29. prompt * Granting the required privileges to the sde user.  
30.   
31. REM grant  ADMINISTER DATABASE TRIGGER to sde;  
32. REM grant  SELECT ANY TABLE to sde;  
33. REM grant  ALTER ANY INDEX to sde;  
34. REM grant  CREATE ANY TRIGGER to sde;  
35. REM grant  CREATE ANY INDEX to sde;  
36. REM grant  DROP ANY INDEX to sde;  
37. REM grant  CREATE ANY VIEW to sde;  
38. REM grant  DROP ANY VIEW to sde;  
39.   
40. prompt * After upgrading you may revoke the following privileges  
41. prompt * Please remove rem from each revoke.  
42. prompt * Revoking the upgrade privileges to the sde user.  
43. REM revoke  ADMINISTER DATABASE TRIGGER from sde;  
44. REM revoke  SELECT ANY TABLE from sde;  
45. REM revoke  ALTER ANY INDEX from sde;  
46. REM revoke  CREATE ANY TRIGGER from sde;  
47. REM revoke  CREATE ANY INDEX from sde;  
48. REM revoke  DROP ANY INDEX from sde;  
49. REM revoke  CREATE ANY VIEW from sde;  
50. REM revoke  DROP ANY VIEW from sde;  

数据拥有者
也是一个比较特殊的用户，也就是说我已某个用户进入ArcSDE连接，然后使用这个用户创建或者导入相关的数据，那么这些数据就是属于我这个连接用户，该用户就是这些数据的数据拥有者。我可以对这些数据进行相关查看、编辑等操作。
Oracle用户来说，在创建这些用户赋予CONNECT和RESOURCE的角色就可以了


普通用户
与数据拥有者相对应的就是普通用户了，普通用户和数据拥有者用户在数据库层次上是没有区别的，但是在业务层次上是属于数据的从属关系，如果普通用户A想要查看数据拥有者用户B的相关数据，那么B就需要为A赋予相关的权限了。这样的一个业务逻辑设置有利于数据的保密性、数据编辑流程的规范化。
那么该用户的角色根据可读和可写自行赋予相关的数据库角色

下面从业务层次上来分析一个这四种用户到底扮演了一种什么样子的角色。

感兴趣请查看：http://blog.csdn.net/linghe301/article/details/7571236

数据库DBA -------------------DBA
ArcSDE管理员-----------------SDE
数据拥有者--------------------Owner
普通用户-----------------------User

一般情况下，我们的业务层次分为三部分，最主要的是数据生产，这些过程中我们会汇集大量的人力来做数据生产工作。主要包括：数字矢量化、数据转换、但是大部分可能是在原有的基础上做相关的编辑工作（增加、删除、修改），这部分一般为owner和大量的user来做，我们可以把owner比作一个部门的项目经理，user比作普通员工，owner为user分配工作，那么对ArcGIS来体现应该就是多用户并发编辑数据，也就是ArcGIS版本的概念，这个我们会在后面单独把这个场景在进行分析。
另外，owner还会对负责数据的字段管理、索引管理、版本管理、权限分配做相关的工作。

如果数据生产工作完成了，那么数据分析就是将我们生产出来的数据进行再“加工”，来生成一些供普通用户、决策者等有价值的查询结果、分析报告、出图报表等，这些工作也是由user来完成就可以了，这些工作一般情况下都是只读的，只要user有可看的权限即可。

还有一项工作是数据库管理，这个就是SDE管理员做的工作了，比如如果需要升级、迁移、备份、性能方面优化等，都需要SDE管理员来做。

最后一个DBA那就是凌驾于所有用户之上了，一般数据库不坏，是不劳他大驾的。

***************************************************************************

***********************典型的应用场景************************************

***************************************************************************

我们接着上面的话题，上面提到在数据生产过程中，一般都是多用户并发来编辑，在保证数据保密以及规范化、责任化的前提下使用了ArcGIS版本的机制。

Owner使用ArcGIS的Privileges功能赋予不同的user可读可编辑的权限，那么使用user用户连接就可以看到owner的数据了，那么每一个user在原有数据的基础上来创建针对于自己的子版本，该版本的属性可以设置为private，保证其他用户不能访问，然后每个用户编辑自己的子版本，然后owner或者专门的user将编辑结果的子版本往父版本进行协调和提交，这样就是一个标准的编辑业务流程。

但是在国内很少使用这种标准的编辑流程，那么在数据保密性、以及编辑过程中往往出现很多因为不规范产生的问题。