Managing Object Name Resolution
Object names referenced in SQL statements can consist of several pieces, separated by
periods. The following describes how the database resolves an object name.
1. Oracle Database attempts to qualify the first piece of the name referenced in the
SQL statement. For example, in scott.emp, scott is the first piece. If there is
only one piece, the one piece is considered the first piece.
a. In the current schema, the database searches for an object whose name
matches the first piece of the object name. If it does not find such an object, it
continues with step b.
b. The database searches for a public synonym that matches the first piece of the
name. If it does not find one, it continues with step c.
c. The database searches for a schema whose name matches the first piece of the
object name. If it finds one, it returns to step b, now using the second piece of
the name as the object to find in the qualified schema. If the second piece does
not correspond to an object in the previously qualified schema or there is not a
second piece, the database returns an error.
If no schema is found in step c, the object cannot be qualified and the database
returns an error.
2. A schema object has been qualified. Any remaining pieces of the name must match
a valid part of the found object. For example, if scott.emp.deptno is the name,
scott is qualified as a schema, emp is qualified as a table, and deptno must
correspond to a column (because emp is a table). If emp is qualified as a package,
deptno must correspond to a public constant, variable, procedure, or function of
that package.
When global object names are used in a distributed database, either explicitly or
indirectly within a synonym, the local database resolves the reference locally. For
example, it resolves a synonym to global object name of a remote table. The partially
resolved statement is shipped to the remote database, and the remote database
completes the resolution of the object as described here.
Because of how the database resolves references, it is possible for an object to depend
on the nonexistence of other objects. This situation occurs when the dependent object
uses a reference that would be interpreted differently were another object present. For
example, assume the following:
■ At the current point in time, the company schema contains a table named emp.
■ A PUBLIC synonym named emp is created for company.emp and the SELECT
privilege for company.emp is granted to the PUBLIC role.
■ The jward schema does not contain a table or private synonym named emp.
■ The user jward creates a view in his schema with the following statement:
CREATE VIEW dept_salaries AS
SELECT deptno, MIN(sal), AVG(sal), MAX(sal) FROM emp
GROUP BY deptno
ORDER BY deptno;
When jward creates the dept_salaries view, the reference to emp is resolved by
first looking for jward.emp as a table, view, or private synonym, none of which is
found, and then as a public synonym named emp, which is found. As a result, the
database notes that jward.dept_salaries depends on the nonexistence of
jward.emp and on the existence of public.emp.
Now assume that jward decides to create a new view named emp in his schema using
the following statement:
CREATE VIEW emp AS
SELECT empno, ename, mgr, deptno
FROM company.emp;
Notice that jward.emp does not have the same structure as company.emp.
As it attempts to resolve references in object definitions, the database internally makes
note of dependencies that the new dependent object has on "nonexistent"
objects--schema objects that, if they existed, would change the interpretation of the
object's definition. Such dependencies must be noted in case a nonexistent object is
later created. If a nonexistent object is created, all dependent objects must be
invalidated so that dependent objects can be recompiled and verified and all
dependent function-based indexes must be marked unusable.
Therefore, in the previous example, as jward.emp is created,
jward.dept_salaries is invalidated because it depends on jward.emp. Then
when jward.dept_salaries is used, the database attempts to recompile the view.
As the database resolves the reference to emp, it finds jward.emp (public.emp is no
longer the referenced object). Because jward.emp does not have a sal column, the
database finds errors when replacing the view, leaving it invalid.
In summary, you must manage dependencies on nonexistent objects checked during
object resolution in case the nonexistent object is later created.
最近做毕业设计老师要求翻译英文文献，想了想没什么翻得，就来翻ORACLE的官方文档吧。下面自己翻得，有不正确欢迎大家指正！
===============================================================================
管理对象名称解析
在SQL语句中被引用的对象名称由被句点分隔开的几个部分组成。下面的部分描述了数据库是如何解析对象名称的。
1. Oracle数据库尝试着限制SQL语句中引用的对象名称的第一个部分。举例来说，scott.emp，其中scott就是第一部分。如果只有一个部分，那么这一部分就被认为是第一部分。
a) 在当前方案下，数据库搜索名称与对象名称第一部分相同的对象。如果没有找到这样一个对象，那么接下来继续b步骤
b) 数据库搜索一个和对象名称第一部分同名的共有同义词。如果没有找到的话，那么接下来继续c步骤
c) 数据库搜索一个和和对象名称第一部分同名的方案名称。如果找到了一个，则返回到b步骤，这时再利用对象名称的第二部分在当前方案下查找符合的对象。如果对象名称的第二部分在这个方案下也没有找到同名的对象，那么数据库会返回一个错误。
如果在步骤c的时候没有找到合适的方案，那么对象则找不到，数据库返回一个错误。
2. 当一个方案对象符合要求之后，名称接下来的部分必须和找到的对象相符合，是个有效的名称。比如说，如果scott.emp.deptno是一个名称，那么scott是一个方案名，emp是一个表，那么deptno必须是一个列名。如果emp是一个包的话，deptno则必须是包中的一个公共常量，变量，存储过程或者函数。
当在分布式数据库中使用一个全局对象名称的时候，不管是显式的或是隐式的使用同义词，本地数据库都会在本地解析这个引用。例如，数据库把一个同义词解析为一个远程表的全局对象名称。则解析语句的部分内容会被转到远端数据库，然后远端数据库再在本地进行对象名称解析，就像上面讨论的那样。
由于数据库解析引用的方式，某个对象可能依赖于一些不存在的数据库对象。这种情况发生在当依赖的对象使用了一个当另外一个对象存在时可能被解析为不同结果的引用的时候。举例来说，假设有如下情况：
当前时刻，company方案包含一个叫做emp的表。
Company.emp的一个名为emp的公共同义词被创建，并且Company.emp的select权限被授予PUBLIC角色。
Jward方案不包含一个名为emp的表或者私有同义词。
用户jward使用如下语句在他的方案下创建了一个视图：
CREATE VIEW dept_salaries AS
SELECT deptno, MIN(sal), AVG(sal), MAX(sal) FROM emp
GROUP BY deptno
ORDER BY deptno;
当jward创建dept_salaries视图的时候，对其中emp这个名称的引用首先会被解析为jward.emp，当做一个表，视图或者私有同义词，如果都不符合，那么就会被当做一个名为emp的公共同义词，这个时候找到了这样的一个同义词。因此，数据库就认为jward.dept_salaries依赖于不存在的对象jward.emp和存在的对象public.emp。
现在假设jward决定要创建一个名为emp的新的视图在他自己的方案下，使用了如下语句：
CREATE VIEW emp AS
SELECT empno, ename, mgr, deptno
FROM company.emp;
注意到jward.emp和company.emp的结构并不一样。
在对象定义当中尝试解析引用的时候，数据库内部会记下这个新创建的对象所依赖的“不存在”的对象—也就是说如果如果这些对象在将来存在了，那么会改变整个对象的定义。如果在后来这个所谓的不存在的对象被创建的话那么这种依赖就必须引起重视。如果一个不存在的对象被创建，那么所有依赖它的对象必须被置为无效状态，这样才能使这些依赖于它的对象得到重新编译和验证，并且所有依赖于它的函数索引都会被标识为不可用。
因此，在前面的那个例子当中，当jward.emp创建了以后，jward.dept_salaries被置为无效，因为它依赖于jward.emp。然后当jward.dept_salaries被使用的时候，数据库会尝试着重新编译这个视图。当数据库解析这个引用为emp的时候，找打了jward.emp（这个时候public.emp不再是被引用的对象了）。因为jward.emp并不包含sal列，所以数据库会在替换视图的时候会发现错误，并把它置为无效状态。
总之，你必须在对象名称解析的过程中管理好在不存在对象上的依赖性，尤其是这些不存在对象在后来会被创建的时候。