Subquery or Inner query or Nested query is a query in a query. A subquery is usually added in the WHERE Clause of the sql statement. Most of the time, a subquery is used when you know how to search for a value using a SELECT statement, but do not know the exact value.

 select ename, deptno, sal
  2   from emp
  3   where deptno =
  4    ( select deptno
  5      from dept
  6      where loc = ‘NEW YORK’ );

ENAME         DEPTNO       SAL
———-           ———     ———
CLARK             10            2450
KING               10            5000
MILLER            10            1300
Subqueries can be used to obtain values for parent select statements when specific search criteria isn’t known. To do so, the where clause in the parent select statement must have a comparison operation where the unknown value being compared is determined by the result of the subquery. The inner subquery executes once, right before the main outer query executes. The subquery returns its results to the main outer query as shown in above example
Notes:
1. Subqueries must appear inside parentheses, or else Oracle will have trouble distinguishing the subquery from the parent query. You should also make sure to place subqueries on the right side of the comparison operator.
2. Subqueries are an alternate way of returning data from multiple tables.
3. Subqueries can be used with the following sql statements along with the comparision operators like =, <, >, >=, <= etc.
     SELECT
     INSERT
     UPDATE
     DELETE

Differnt Usage
IN
You can also use the in comparison, which is similar to the case statement offered in many programming languages, because resolution can be established based on the parent column’s equality with any element in the group. Let’s take a look at an example:
SQL> select ename, job, sal
  2  from emp
  3  where deptno in
  4   ( select deptno
  5     from dept
  6     where dname in
  7     (‘ACCOUNTING’, ‘SALES’));
EXISTS/NOT EXISTS
Another way of including a subquery in the where clause of a select statement is to use the exists clause. This clause enables you to test for the existence of rows in the results of a subquery, and its logical opposite is not exists. When you specify the exists operation in a where clause, you must include a subquery that satisfies the exists operation. If the subquery returns data, the exists operation returns TRUE, and a record from the parent query will be returned. If not, the exists operation returns FALSE, and no record for the parent query will be returned. Let’s look at an example in which we obtain the same listing of employees working in the New York office, only this time, we use the exists operation:
SQL> select e.ename, e.job, e.sal
  2  from emp e
  3  where exists
  4     ( select d.deptno
  5       from dept d
  6       where d.loc = ‘NEW YORK’
  7       and d.deptno = e.deptno);

ENAME      JOB              SAL
———-     ———           ———
CLARK      MANAGER        2450
KING        PRESIDENT      5000
MILLER      CLERK             1300
Correlated Subquery
A query is called correlated subquery when both the inner query and the outer query are interdependent. For every row processed by the inner query, the outer query is processed as well. The inner query depends on the outer query before it can be processed.
SELECT p.product_name FROM product p
WHERE p.product_id = (SELECT o.product_id FROM order_items o
WHERE o.product_id = p.product_id);

Listing and Writing Different Types of Subqueries
The following list identifies several different types of subqueries you may need to understand and use on the OCP exam:

  •       Single-row subqueries The main query expects the subquery to return only one value.
  •       Multirow subqueries The main query can handle situations where the subquery returns more than one value.
  •       Multiple-column subqueries A subquery that contains more than one column of return data in addition to however many rows are given in the output. These types of subqueries will be discussed later in the chapter.
  •       Inline views A subquery in a from clause used for defining an intermediate result set to query from. These types of subqueries will be discussed later in the chapter.
Oracle Installed Base can track an item instance from the time that it is received in inventory, in work in process, in projects, at customer sites, and throughout the return and repair process.


Item Instance Attribute Change Tracking
Oracle Installed Base is a centralized repository of information for an item instance and its tracking details including location, status, ownership, party role, and contact relationships. It also supports the creation and maintenance of Oracle Installed Base configurations.
Counters can be tied to item instances so that usage can be captured. For example, if an item instance is an electrical meter, then counters can be used to store the meter reading, thus recording the usage that in turn generates revenue.

History of Item Instance Changes
Oracle Installed Base records a history of changes to item instances.
For each item instance in Oracle Installed Base, a history of transactions is tracked and stored. Given a particular time frame, these transactions and the state of the attributes during that time can be viewed.
The transaction history includes a list of inventory, work in process, order management, and other transactions affecting an item’s tracking attributes.

The Oracle applications that use Oracle Installed Base are shown the picture.
Several Oracle Order Management, Purchasing, Inventory, Work in process transactions interact with Oracle Installed Base. Oracle Installed Base can track both shippable and non-shippable items.
Purcahse Order
In case of purchase orders when the receipt of materials is completed, system increases the Inventory on hand. If installed Base is used then the tracking of the material is also started with the receipt completion. Installed Base creates an item instances for each of the received items which are marked as ‘Tracked in Installed Base’.
Order Management
A sales order shipment generates an Inventory Issue material transaction in Oracle Inventory application. Because Oracle Installed Base also tracks the internal inventory for trackable items, the instance already exists in Oracle Installed Base. A shipment can result in a change in instance location and ownership, status, and so on, based on the associated Oracle Installed Base transaction subtype.
 All All the functionalities of installed base module can be accessed with Installed Base User responsibility. And to access the’ Installed Base User’ responsibility’ the user must be assigned to CSI_NORMAL_USER role.
Follow the below setups to assign the required roles to Installed Base Users

1. Login to the instance with sysadmin user and select CRM HTML Administration responsibility
2. Navigate to Setup : Users : Registration: user Maintenance
3.  Query the user name, click on the hyperlink for the user
4.  Add the CSI_NORMAL_USER role. Update.
The responsibility “Install Base User” is obsolete in Release 12.  The new responsibility is called ‘Oracle Installed Base Agent User’
Notice that the Role assignment via CRM HTML administrator is for Oracle Installed Base User responsibility (ie. JTT page). Oracle Install Base Agent User responsibility is a new one in R12.

Profile Options
The Important Profile Options which needs to be set at the site level are
Service: Inventory Validation Organization
CSI: Default Instance Status


Oracle Installed Base is an item instance life cycle tracking application that facilitates enterprise-wide life cycle item management and tracking capability.
You specify which items you want to track in the Master Item list in Oracle Inventory. Subsequently, when a particular real-world instance of the item is created, an item instance record is created in Oracle Installed Base. Any significant changes to the item instance will also be recorded in Oracle Installed Base.

Tangible Items
Item instances can be used to track tangible items, that is, physical, real-world objects, that can be assembled and shipped, such as computers, engines, machine parts, and so on.
Intangible Items
Item instances can be used to track intangible items such as software, services, licenses, and agreements. For example, a telephone number can have different services such as call waiting and conference call. These can all be defined and tracked as components of the telephone service.
Serialized Items
When a trackable item is defined in Oracle Inventory as serialized, each item instance derived from that item requires a unique serial number and individual tracking. The item instance will always have a quantity of 1.
Non-Serialized Items
When a trackable item is defined in Oracle Inventory as non-serialized, it is typically for smaller objects whose real-world instances do not require individual tracking. For example, a screw could be defined as a non-serialized, trackable item; an order for 100 screws would result, after order shipping, in the creation of one item instance, with  quantity 100.