Oracle同义词的好处

Oracle数据库中提供了同义词管理的功能。同义词是数据库方案对象的一个别名，经常用于简化对象访问和提高对象访问的安全性。在使用同义词时，Oracle数据库将它翻译成对应方案对象的名字。与视图类似，同义词并不占用实际存储空间，只有在数据字典中保存了同义词的定义。在Oracle数据库中的大部分数据库对象，如表、视图、同义词、序列、存储过程、函数、JAVA类、包等等，数据库管理员都可以根据实际情况为他们定义同义词。通过Oracle数据库同义词管理，可以给数据库管理员与应用程序开发人员带来不少惊喜。　　好处一：应用程序开发可以不管数据库的具体对象名。

　　在应用程序中，要不断的调用Oracle数据库的对象，如表、视图、对象等等。为此，在管理软件开发的过程中，若应用程序已经完成了某部分功能的开发。此时，数据库管理员若一定需要更改某个数据库对象的命名。那么，此时应用程序也需要调整。这在实际工作中，会很不方便。特别是有些应用程序如果提供了功能自定义平台的话，会非常的麻烦。如在一个ERP软件中，有报表自定义功能。在系统中，原来就有一张供应商产品明细表。但是，用户觉得这张报表信息不够齐全。用户希望能够显示出某个零件所对应的成品。此时，用户可以更改原有的数据库对象来完成这个自定义。但是，这往往不被建议这么做。因为若不小心修改错误，那么就很难再修改回来。所以自定义平台中，若需要对原有报表进行比较大的变更时，往往建议用户另外建立一个视图，来收集自己所需要的信息。若这么做的话，那么用户不仅需要定义数据库对象，而且还要重新调整前台应用程序的报表格式。显然这工作量有多大。

　　而现在有了同义词功能的话，这一切都会变得方便。因为前台应用程序可以不用作调整，而只需把数据库对象同义词进行重新定义即可。这既保障了前台应用程序的可恢复性;同时也降低了工作量。这就是Oracle数据库同义词给我们带来的第一个惊喜。

　　好处二：避免应用程序直接访问数据库对象，提高数据库安全性。

　　在开发数据库应用程序的时候，应当普遍遵守的一个规则是尽量避免直接饮用数据库的表、视图、函数或者其他对象。因为这会在很大程度上破坏数据库的安全性。

　　如在前台应用程序中直接调用数据库对象，那么攻击者只需要对应用程序所引用的对象进行分析，就可以很容易的了解后台数据库的基本逻辑结构。这显然会为攻击者提供很大的便利。所以，为了保障数据库的安全，前台应用程序最好通过同义词来访问后台数据库。如此的话，攻击者就很难通过前台应用程序的调用，来分析后台数据库的对象，以及对象之间的关系。

　　好处三：简化数据库对象的访问。

　　有时候，我们某个数据库对象的名字可能会很长，如AD_USER_ROLE_NAME_TRL。若每次调用这个数据库对象的时候，都要输入这么长的对象名，肯定会让数据库管理员很头疼。但是，若名字定义的太短了呢，可读性就不好。其他一些数据库，只有牺牲可读性，把数据库对象的名字尽量缩短。

　　不过在Oracle数据库中，则可以不用这个烦恼。因为我们可以给这个数据库对象设置一个同义词，就好像别名一样。如此的话，在访问的时候，只需要通过同义词访问即可，而不需要输入这么长的对象名。

　　除了上面三个应用之外，在分布式数据库系统中，为存储在远程数据库中的对象创建同义词，使用户可以像使用本地对象一样对远程对象进行操作，就不需要提供网络连接名进行限定了。显然，这也会给一些分布式数据库管理员带来很大的便利。

　　Oracle数据库同义词有两种类型，分别是公用同义词与方案同义词。

　　公用同义词由一个特殊的用户组Public所拥有。顾名思义，数据库中所有的用户都可以使用公用同义词。公用同义词往往用来标示一些比较普通的数据库对象，这些对象往往大家都需要引用。在引用这些对象时，并不需要在其前面添加一个Public所有者名字作为限定。否则的话，如果在一个公用同义词前加上一个Public，就是画蛇添足，系统反而会给出一个错误提示。不过在实际应用中，笔者不建议用户采用公用同义词。因为现在系统中，公用同义词已经有很多。若用户仍然为数据库定义公用同义词的话，不能够起到简化数据库对象访问的作用。

　　方案同义词是跟公用同义词所对应，他是由创建他的用户或者方案所有。故也被称为私有同义词。当然，这个同义词的创建者，可以控制其他用户是否有权使用属于自己的方案同义词。方案同义词经常在应用程序开发中使用，为应用开发提供命名上的解决方案。如当一个数据库对象，如一张表，被重命名或者被复制成新的表时，并且新名字与老名字都需要使用的情况下，数据库管理员就可以使用方案同义词，即为老名字和新名字都建立专用同义词，不过他们都同时指向同一个数据库对象。

　　其实创建方案同义词也很简单。不过其必须要有一个前期条件，就是必须要拥有一定的权限，如CREATE SYNONYM权限，若是要在他人的方案中建立同义词的话，则还必须拥有CREATE ANY SYNONYM权限等等。这些是必须遵循的首要条件。否则的话，就不能够建立同义词。

　　另外需要注意的是，即使在数据库对象不存在的情况下，也可以为预计要建立的数据库对象设置同义词。这个特性很好用，它可以帮助数据库开发团队或者应用程序开发团队进行更高的协作。如只要数据库管理员跟应用程序预先做好对象的命名与同义词的定义工作，那么即使数据库管理员还没有开发好某个数据库对象，前台应用程序开发人员也可以通过引用同义词的方式引用为建立的数据库对象。如此的话，就不会因为某一步工作没有完成而给其他人的工作带来什么负面影响。

　　在方案同义词使用的过程中，还需要注意以下几个问题。

　　一是要注意使用自己的方案与他人方案的同义词方法有一定的差别。当用户在自己的方案内建立同义词后，用户就有对象的所有权限。可以像使用原来的数据库对象那样，使用这个对象的同义词。如查询数据、插入修改删除纪录等等。但是，与公用同义词不同，无论是否给其他用户授予如何使用方案同义词所对应的对象的对象权限，都不能够使用方案同义词，因为同义词是私有的。也就是说，如果有一张USER表。用户A虽然有CREATE ANY SYNONYM权限，可以为这个数据库对象建立同义词。但是，其没有这张表的Select权限。则用户A仍然不能够利用这个同义词来访问这个数据库对象。否则的话，数据库会提示“表或者视图不存在”。若A用户想要通过同义词访问这个User表的话，则必须拥有这个表的Select等对应的权限，才能够利用同义词对这个表进行对应的操作。也就是说，通过自己的方案中创建指向其他方案中的对象的方案同义词，只有在被授予了如何访问对象的对象权限之后，才可以按对象权限访问对象。另外需要注意，由于方案同义词是私有的，所以，其他用户使用自己方案同义词的话，在任何情况下，即使拥有某个对象的相关权限，也无法进行访问。这就是方案同义词的私有本质。

　　二是要注意Oracle数据库中的名称解析顺序。如我们通过FROM user 这个子句访问某个表的时候，数据库是如何来查询数据库中是否存在这个对象呢?他是有一定的解析顺序的。当我们书写的程序代码中若引用了一个未限定的数据库对象，如表、视图、存储过程等等，数据库会根据一定的顺序去查询是否有被引用的对象。通常情况下，会按如下的顺序进行验证。首先是看看当前用户是否拥有这个对象;其次这个对象名是否是当前用户拥有的一个同义词;最后，才去判断公用同义词的情况。所以，在实际应用中，我们数据库管理员要尽量利用方案同义词，少用公用同义词。这对提高数据库的运行效率还是很有帮助的。

　　三是数据字典视图就是公用同义词的一个好例子。有时候，我们可以借鉴他的配置来管理我们的公用同义词与方案同义词。在实际工作中，我们也可以预先把所有的数据库对象名设计好，并配上所有的同义词。然后利用脚本进行一次性生成。若一个个去生成同义词的话，在其工作量还是蛮大的。

下面给出实际工作中，我建立的同义词，因为是两个不同服务器上的用户，所以先要把74.5和74.9这两台机上的库连接起来。在74.9上的product_new_app库中要建立一个同义词RES_MOBILE_PRODUCT，但这个RES_MOBILE_PRODUCT是在74.5上，所以先要连接74.5，再建立同义词



1、在74.9上建立数据库连接，连接到74.5上的MOBILE_RES_APP这个用户，TEST745_mobile为自定义的名称-别名，用户名：MOBILE_RES_APP，密码：MOBILE_RES_APP， test745是745这台机的PID

CREATE PUBLIC DATABASE LINK "TEST745_mobile"  

CONNECT TO "MOBILE_RES_APP" IDENTIFIED BY "MOBILE_RES_APP" 

USING 'test745';

2、在  PRODUCT_NEW_APP这个用户上执行，建立视图语句，视图名称RES_MOBILE_PRODUCT是自己定义的，主要是@TEST745_mobile连接上面建立的连接名称

CREATE OR REPLACE SYNONYM "PRODUCT_NEW_APP"."RES_MOBILE_PRODUCT" FOR "RES_MOBILE_PRODUCT"@TEST745_mobile;