New object-oriented databases provided some stiff competition for Oracle's relational model.
Several features in object-oriented database allowed users to:

1. Define their own data types
2. Directly represent aggregate objects
3. Navigate between tables with pointers
4. Create non-first normal form tables with repeating groups

All of the object-oriented programming (OOP) features of Oracle shown in this course have shared two characteristics:

1. they are embedded objects, and
2. they are column objects.

An embedded object is one that is completely contained within another. For example, a nested table is contained within a table, so it is an embedded object.
Although a nested table's data is stored apart from the main table, its data can only be accessed via the main table. A column object is one that is represented as a column in a table. For example, a (varray) varying array is represented as a column in a table, so it is a column object.
To take advantage of OOP capabilities, a database must also support row objects, which are objects that are represented as rows instead of columns. The row objects are not embedded objects. Instead, they are referenced objects, accessible by means of references from other objects. This module discusses how row objects are created and referenced.
Row objects can be extended for use within some of the objects discussed previously (such as object views). In addition to row objects, this module covers the application of objects to PL/SQL, by means of creating Object PL/SQL.

The relational model is too granular and introduces granularity by removing duplication. The result is a database model nearly always highly effective for front-end application performance and OLTP databases. OLTP databases involve small amounts of data accessed frequently and concurrently by many users. On the other hand, data warehouses require throughput of huge amounts of data by a small user population. OLTP databases (the relational database model) need lightning-quick response to many people and small chunks of data. Data warehouses perform enormous amounts of I/O activity, over millions of records. It is acceptable for data warehouse reports to take hours to run.

The object model is even more granular than the relational model, just in a different way, even if it does appear more realistic to the naked eye. Highly granular normalized relations (the relational model), or uniquely autonomous objects (the object model), can cause serious inefficiencies in a data warehouse. Data warehouses perform lots of big queries, with lots of data in many records in many tables. The fewer tables there are in a data warehouse, the better the data repository from a performance perspective. Query joins on large sets of records can become completely unmanageable and even totally useless.

The 1989 Object-Oriented Database System Manifesto proposed thirteen mandatory features for an OODBMS, based on two criteria: it should be 1) an object-oriented system and 2) database management system.

1. Complex objects must be supported: It must be possible to build complex objects by applying constructors to basic objects. The minimal set of constructors are SET, TUPLE, and LIST (or ARRAY). The first two are important because they have gained widespread acceptance as object constructors in the relational model. The final one is important because it allows order to be modeled. Furthermore, the manifesto requires that object constructors must be orthogonal: any constructor should apply to any object. For example, we should be able to use not only
   

   SET(TUPLE()) and LIST(TUPLE())
   

   
   but also

   TUPLE(SET()) and TUPLE(LIST()).		
   

2. Object identity must be supported: All objects must have a unique identity that is independent of its attribute values.
3. Encapsulation must be supported. In an OODBMS, proper encapsulation is achieved by ensuring that programmers have access only to the interface specification of methods, and the data and implementation of these methods are hidden in the objects. However, there may be cases where the enforcement