Complete overview of OO features in Oracle DB, use cases, real behaviour, tricky limitations, optimization, administration hints.

1. Oracle Objects and Transactional Systems Andrea Parrilli Oracle and Java Developer [email_address]

2. Topics - OID and Primary Key - REFs and Foreign Keys - Substitutability - Collections - Type evolution - Encapsulation - Inheritance - Polymorphism - Identity Objects for storage OOP in Oracle Objects as a developer tool - Casting - Static - References

3. OOP in Oracle - Not really available - Objects must be storable - Not exactly as column security GRANT … ON <table>(<list of fields>) … - Different scopes: “user scope” vs. “code scope” Who's asking (authorized user vs. unauthorized user) vs. Where are we (local vs. global context) Encapsulation - Single inheritance - No abstract types: just declare the type [NOT] INSTANTIBLE If a non implemented method is called then ORA-04067 - Extendability declared through [NOT] FINAL Inheritance

4. OOP in Oracle - Compile or Runtime - Overriding: Specialize subtypes methods - Overloading: Specialize methods on input parameters: available since the beginning in PL/SQL - Dynamic method dispatch: at runtime the right method is chosen depending on the object type Polymorphism Select case when T. shape is of ( MyCircleType ) then 'MyCircleType' when T. shape is of ( MyRectangleType ) then 'MyRectangleType' end SubType, T. shape . area () Area from MyShapeTab T SUBTYPE AREA --------------- ---------- MyCircleType 3,14 MyRectangleType 200

5. OOP in Oracle create or replace type MyShapeType as object ( Color varchar2(10), member function area return number ) not final instantiable; create or replace type MyCircleType under MyShapeType ( Radius number, Overriding member function area return number ) not final; create or replace type body MyCircleType is Overriding member function area return number is begin return 3.14*Radius*Radius; end; end; create or replace type MyRectangleType under MyShapeType( SideA number(8), SideB number(8), overriding member function area return number ) not final; create or replace type body MyRectangleType is overriding member function area return number is begin return SideA*SideB; end; end; create table MyShapeTab(shape MyShapeType); insert into MyShapeTab values(MyCircleType('blue', 1)); insert into MyShapeTab values(MyRectangleType('red', 10, 20)); commit;

6. OOP in Oracle Relational approach to represent many types - One table per type (too many tables, complex queries, difficult maintenance ) - One table to store type metadata, one or more tables to store instances' values (slow method, many joins, application can corrupt data) Object Relational approach to represent many types - One object relational table per type function (business related) - allows better performance than the “melting pot” approach, neater design - Accurate storage design (see substitutability) - More logic inside database objects - Less database objects to maintain

7. OOP in Oracle Reflection - First cited in 1982, B. C. Smith - Widely available in interpreted languages with easy interfaces - In databases since first design (dictionary) - DBMS_METADATA package, we can get XML representation of any DB object, then parsing is needed (still too complicated to be widespread tool) Identity - in OOP objects are always strong entities (every instance has its own pointer, cloning must be explicitly declared): always passed by reference. - in OOP programmers do not usually care to define a “primary key” - in DB entities are weak by default, can be made strong - to implement object identity and referencing Oracle provides OID (Object Identifier), and REFs. - this is tricky! In OOP when we want to compare two instances we can do it on an object level (comparing pointers) or on a value level (comparing attributes). Oracle uses only the pointers (the OID) to compare objects when replicating, so when updating an object we must take care not to substitute it but change the attributes values (see replication guidelines)

8. OOP in Oracle OID - Can be Oracle-managed - RAC-wide 16 bytes unique identifier - or Primary key based (uses as much space as the PK) REF - Unscoped REF: OID plus DB-object-id - Scoped: just the OID - Unscoped with ROWID: unscoped REF plus 10 bytes ROWID hint. This is a violation of the relational paradigm! Can lead to disrupted ROWIDs: ANALYZE … VALIDATE REF Referential integrity - REFs are not Foreign Keys: you have to define and enforce them by yourself, a disrupted reference is said to be “dangling” ANALYZE … UPDATE SET DANGLING TO NULL

9. Objects as a programming tool Object support is available in SQL and PL/SQL SQL: downcasting (narrowing) CREATE TABLE shapes OF MyShapeType; INSERT INTO shapes VALUES(mycircletype('red', 33)); INSERT INTO shapes VALUES(myrectangletype('blue', 11, 22)); SELECT TREAT(VALUE(s) AS MyCircleType).radius FROM shapes s ORDER BY 1 NULLS FIRST; TREAT(VALUE(S)ASMYCIRCLETYPE).RADIUS ------------------------------------ 33 TREAT will return null if the argument is not in the lineage of the destination type. In SQL method calls on nulls are null! Quite different from Java ... But in PL/SQL access into null exception is risen

10. Objects as a programming tool Object support is available in SQL and PL/SQL SQL: upcasting (widening) is implicit Note that when a field is not substitutable the insertion of a subtype, even upcasted, will generate an error! CREATE TABLE abstract_shapes OF MyShapeType NOT SUBSTITUTABLE AT ALL LEVELS; SQL> INSERT INTO abstract_shapes 2 SELECT TREAT(VALUE(s) AS MyShapeType) FROM shapes s; SELECT TREAT(VALUE(s) AS MyShapeType) FROM shapes s * ERROR at line 2: ORA-00932: inconsistent datatypes: expected - got UDT

11. Objects as a programming tool CREATE OR REPLACE TYPE superclass AS OBJECT ( sup NUMBER, CONSTRUCTOR FUNCTION superclass RETURN self AS RESULT, MEMBER PROCEDURE init_superclass(self IN OUT NOCOPY superclass), NOT FINAL MEMBER FUNCTION do_something RETURN NUMBER ) NOT FINAL INSTANTIABLE; PL/SQL: Example

12. Objects as a programming tool CREATE OR REPLACE TYPE BODY superclass IS CONSTRUCTOR FUNCTION superclass RETURN self AS RESULT IS BEGIN self.init_superclass(); RETURN; END superclass; MEMBER PROCEDURE init_superclass(self IN OUT NOCOPY superclass) IS BEGIN self.sup := 33; END; NOT FINAL MEMBER FUNCTION do_something RETURN NUMBER IS BEGIN return self.sup; END do_something; END;

13. Objects as a programming tool CREATE OR REPLACE TYPE subclass UNDER superclass ( sub NUMBER, CONSTRUCTOR FUNCTION subclass RETURN self AS RESULT, MEMBER PROCEDURE init_subclass(self IN OUT NOCOPY subclass), OVERRIDING MEMBER FUNCTION do_something RETURN NUMBER, MEMBER FUNCTION only_sub RETURN NUMBER ) FINAL INSTANTIABLE;

14. Objects as a programming tool CREATE OR REPLACE TYPE BODY subclass IS CONSTRUCTOR FUNCTION subclass RETURN self AS RESULT IS BEGIN self.init_superclass(); self.init_subclass(); RETURN; END subclass; MEMBER PROCEDURE init_subclass(self IN OUT NOCOPY subclass) IS BEGIN self.sub := 11; END init_subclass; OVERRIDING MEMBER FUNCTION do_something RETURN NUMBER IS BEGIN RETURN self.sub; END do_something; MEMBER FUNCTION only_sub RETURN NUMBER IS BEGIN RETURN 77; END only_sub; END;

15. Objects as a programming tool DECLARE o superclass := new subclass(); –- sub=11, sup=33 BEGIN -- this will genereate an error -- dbms_output.put_line('sub=' || o.sub); dbms_output.put_line('sub=' || TREAT(o AS subclass).sub); -- these will generate an error too -- dbms_output.put_line('only_sub(): ' || o.only_sub()); dbms_output.put_line('Overridden as superclass: ' || TREAT(o AS superclass).do_something()); dbms_output.put_line(o.do_something()); END; sub=33 Overridden as superclass: 33 33 PL/SQL procedure successfully completed.

16. Objects as a programming tool Static scope - Can define static methods, when the the object context is not needed, this slightly improves performance - Static properties are forbidden: objects must be storable Where to store static properties? The dictionary? What with old instances? Problems ... Application design should be very accurate on how to manage them. Although something like “VOLATILE” property, not stored but used in internal mechanisms of the class could be useful, for example to use PL/SQL types, and from that to STATIC VOLATILE, there is not this much distance When a static scope is needed use a package, they very look like singletons of purely static classes.

17. Objects as a programming tool REF in PL/SQL DECLARE R REF MyClass; S MyClass := new MyClass(33, 11); BEGIN R := REF(S); … This simply won't work: a REF is not a pointer in memory or an object id as in PHP or Java. It rather is a pointer to the storage area where the object - is held. How do I share the same object between two classes? As far as I know you can't: - NOCOPY is just an hint; - even if it was always applied we miss something like RETURN NOCOPY - default is cloning, copying

18. Objects as a programming tool How to build a session-scoped service class? Instead of storing the service classes (can be very complicated and will introduce many nested tables and object tables just to hold few instances, or just one) and getting a REF to it, may be advisable to use packages in the way the Oracle framework ( DBMS_* , UTL_* , etc.) is programmed. - Get a service id from the package: this correspond to getting an instance of the service class through a Factory. To program this in PL/SQL is easy: every instance property becomes a TABLE OF <that_property_type> INDEX BY PLS_INTEGER , the latter is the service id and even if said property is itself a table, it would work anyway, because a table is a valid base type for a PL/SQL table. - In every service call include the service id: in an OO language this is done by the compiler when you invoke a method on an instance: obj.method(param) -> method_proc(&obj, param); - Share the service id with all the components needing it as you would share an instance of the class; - Upon termination release the resources!

19. Objects as a programming tool How to build a instance -scoped service class? Business Delegate pattern - One session runs the service (server, BusinessService) - Others access this service by means of a stub, the BusinessDelegate, which in turn exposes all the relevant business methods, and instead of executing their logic locally, simply invoke the server’s methods over a link. - The only logic needed in the business delegate is the use of LookupService to get the link to forward the messages to the server and get back the response. On single instances Pipes (DBMS_PIPE) are an excellent link and Lookup. All the logic can be coded in just one package!

20. Objects as a programming tool Object Types are tensors (as opposed to scalars) and as such they do not have a predefined ordering in their dominion. To provide this ordering we may define an ORDER or MAP method (not both) in the type to provide ordering: the first performs the comparison in the method body itself returning 1, 0 -1 depending on the comparison outcome (>, =, <) and this opacity implies the optimizer has limited freedom of organizing the sort process other than nested looping on the entries; the second method, instead, maps the object to a scalar value allowing for hash sorts. Thus it is recommended to define, when possible, a MAP method rather than an ORDER. Ordering Objects

21. Object Storage Two kinds of table in Oracle: Relational and Object Relational (OR) CREATE TABLE object_relational OF <some_type> (R) CREATE TABLE relational (some_type <some_type>) OID and PK CREATE TABLE Person OF Person_o ( CONSTRAINT person_pk PRIMARY KEY (tax_id) … ) OBJECT IDENTIFIER IS PRIMARY KEY; Indeed even if a primary key is defined, you can keep the generated OID as object identifier. This could be the case when your primary key is bigger than 16 bytes. But design consideration could require the usage of a PK anyway, as OIDs are opaque.

24. Object Storage SQL> desc myshapetab Name Null? Type -------------------------- -------- ---------------------------- SHAPE MYSHAPETYPE SQL> set describe depth all SQL> desc myshapetab Name Null? Type -------------------------- -------- ---------------------------- SHAPE MYSHAPETYPE MYSHAPETYPE is NOT FINAL COLOR VARCHAR2(10) METHOD ------ MEMBER FUNCTION AREA RETURNS NUMBER Getting Information on Types

25. Object Storage select name, length, precision# from sys.col$ where obj# = (select object_id from user_objects where object_name = 'MYSHAPETAB'); NAME LENGTH PRECISION# ------------------------------ ---------- ---------- SHAPE 256 SYS_NC00002$ 16 SYS_NC00003$ 10 SYS_NC00004$ 22 SYS_NC00005$ 22 8 SYS_NC00006$ 22 8 How is Oracle storing Objects? (1) - A virtual column; - 16 bytes OID of the object; - 10 bytes for the color field in the base class MyShapeType; - 22 bytes for the unconstrained number MyCircleType.radius; - 2x22 bytes for the constrained sides of MyRectangleType; - Not shown here are also a small amount of space (usually one bit from v10 on) to represent the nullity of an Object (as opposed to an Object with all null attributes) and the TYPE_ID hidden column, varying from 1 to 4 bytes, to record the actual subtype stored.

26. Object Storage How is Oracle storing Objects? (2) If we do not specify otherwise Oracle is representing the whole type hierarchy originating from the base type of the table in the table itself so that it can accommodate indifferently objects of all the types into it. Every sibling in the hierarchy is using a projection of the table, ignoring its siblings' properties

27. Object Storage Oracle offers an option to restrict the substitutability on one object column to one specific type via the predicates [NOT] SUBSTITUTABLE AT ALL LEVELS and IS OF (ONLY <type>). Controlling Object Storage create table MyShapeNotSubs of MyShapeType not substitutable at all levels; insert into myshapenotsubs values (mycircletype('INDIGO', 22)) * ERROR at line 1: ORA-00932: inconsistent datatypes: expected - got UDT select name, length, precision# from sys.col$ where obj# = (select object_id from user_objects where object_name = 'MYSHAPENOTSUBS'); NAME LENGTH PRECISION# ------------------------------ ---------- ---------- SYS_NC_OID$ 16 SYS_NC_ROWINFO$ 1 COLOR 10

28. Object Storage The importance of substitutability derives also by the fact that whenever a subtype is added to the hierarchy, all the tables having substitutable columns of the supertype's type are altered to accommodate the new subtype's attributes. Also when a subtype is dropped, the VALIDATE option removes the subtype's column from all the relevant tables. This can be accomplished after type evolution by the use of ALTER TABLE ... UPGRADE Notes on Object Storage Table-wide substitutability clauses are incompatible with more fine grained COLUMN <column> IS OF … And for object tables turning off all substitutability means even object aggregated under the table type are not substitutable. See next page

29. Object Storage CREATE TYPE aggregated AS OBJECT (shape myshapetype) NOT FINAL INSTANTIABLE; CREATE Type aggregated_sub UNDER aggregated (circle mycircletype) FINAL INSTANTIABLE; CREATE TABLE aggregate_sub_t OF aggregated_sub NOT SUBSTITUTABLE AT ALL LEVELS; SQL> insert into aggregate_sub_t values ( 2 myshapetype('RED'), mycircletype('BLUE', 33)); 1 row created. Notes on Global Substitutability SQL> insert into aggregate_sub_t values ( 2 mycircletype('RED', 44), mycircletype('BLUE', 33)); mycircletype('RED', 44), mycircletype('BLUE', 33)) * ERROR at line 2: ORA-00932: inconsistent datatypes: expected MONDO.MYSHAPETYPE got MONDO.MYCIRCLETYPE

30. Object Storage They model a Weak Entity. Have you ever seen one? If you have information in your DB then you are going to query it. Nested tables and Varrays - nested tables have no theoretical upper bound while varrays are fixed length lists; - nested tables are stored in another table than the one using them, thus implicitly generating a JOIN operation at query time. Varrays are stored inline (if they fit the maximum atomic column length of 4000 bytes) as raw value or, if bigger, as LOBs (beware if using clustered tables, LOBs are not supported) with less overhead than nested tables. Their manipulation, on the contrary, is more heavy since their update involves the substitution of the entire collection with the updated one, while nested tables are manipulated row by row. - Nested tables can be manipulated by SQL while varrays can't. You can ask a varray if it contains a value but you cannot add one without a little PL/SQL (working with types this isn't such a big deal); - Ordering: nested tables do not define any intrinsic ordering, while varrays are inherently ordered collections; Differences

31. Object Storage - Nested tables add a 16 bytes unique RAW key to the parent table, key which is stored on the nested table to perform joins, called NESTED_TABLE_ID. Beware, Oracle does not create an index on the storage table for the NESTED_TABLE_ID! - - Every nested table in a table adds its own unique key, which is a waste of space - Nested tables cannot be directly referenced by Queries (without tricks) - You cannot define foreign keys or triggers on them Nested Tables Cons Nested Tables Pros - Optimization hint: RETURN AS VALUE/LOCATOR. In the first case the nested table data is fetched and sent along with the query data, in the second only a pointer to that data is sent to the application, and the access to that data triggers the fetch of the actual content (like a REF CURSOR, or a LOB with RETURN AS LOCATOR). - Can be made IOT: after all their use case is navigation from parent to children ...

32. Object Storage Once an Type has a dependency it is no more replaceable. This is because Objects must be storable, thus dropping and recompiling would mean leaving all the tables with old instances without a definition. They can be altered like a table with same attributes and the substitutability, extendability and instantiability can be modified. Methods and constructors signatures can be modified. All method implementations (the type body) are freely modifiable Type Evolution - Unlike OO languages classes, changing a type is way more difficult than just recompiling the class! - Changing a type has potential effects on many tables: must be done carefully. This latter problem is not really a problem if seeing the question from the data model point of view. If you need a new attribute to describe an entity then you have to add it whenever the entity appears. In an OR design you can do it by changing the type definition, while in a pure Relational design you have to manually change all the occurrences of that type.

33. Conclusions - In PL/SQL units, as a support tool to define PL/SQL tables - In tables to optimize navigation: REF WITH ROWID - In tables to neatly define your data model - In tables to support common mechanisms for auditing, historical queries, ... When/where to use Objects? - To program frameworks or services - To implement a full OR schema using nested tables - Nested tables are bad. Use standard tables instead or varrays if they fit and updates are infrequent It is true OR database design is nearer to the applications' way of representing and manipulating data, but applications change over time, data stands (T. Kyte) When/where to use Objects? When/where NOT to use Objects?

34. Q&A