Oracle Objects And Transactions

Editor's Notes

• #3: Glossary and Abbreviations: Type (Class): the “description”, of a functional unit loosely coupled to other functional units which includes attributes describing its state and methods changing that state. If the “building instruction” aren’t detailed enough to allow someone to actually build and use the type, then it is said to be an abstract type . Instance of a Type (Object): one example of the type, a concrete object built following the instructions given in the type definition. Member: if talking of a specific type instance then a member is any of its attributes or methods, if talking of a type as a set, then members are instances of that type. R: concerning the relational tables. OR: Object relational, concerning the representation of objects by means of a relational database.
• #4: Encapsulation A feature that hides the complexities of a type from the user’s point of view. Ex. The user is usually interested in driving a car, not to detail how pushing the brake pedal is increasing the pressure on the brake primary oil circuit, which moves a membrane in a servo-mechanism, which multiplies the exertion etc. In Oracle this feature is not available, and for a reason, I guess: object must be storable as they are and encapsulation would imply the inaccessibility from the “ouside of the object” of some properties, but for this purpose there is already the column based security: GRANT … ON <table>(<list of fields>) … which is way more fine grained than the access modifiers in common OO languages (except, for example, the C++ family which has the concept of “friend” types), and yet is lacking the concept of local vs. global context opposition: the gobal context is seeing the type from the outside, which is the standard point of view of a User in Oracle, so it ignores protected and private members, while the local context is the one of a method executing on the type, which exists only inside the type methods. Unless another kind of privilege (local_context?) is created there would be no way to access the local information. Thus all attributes and methods are implicitly public. Inheritance Inheritance is the property of classes which allow them to be specified at different levels of abstraction, from the most abstract level to most practical one. Ex. A MeanOfTransportation is an abstract type for sails, trains, planes, cars, … the next level may be “Vehicle” which includes cars, TIRs, Trikes, …, then we have the Car (Audi, Fiat, VW, …) which includes all the specifics of any single model, then we have MyCar, which is able to refuse to start when it’s too cold and reproduces the characteristic shrieks whenever the doors are open. Here we do not discuss the multiple inheritance (as is in C++, for example) because in the database technology it has more downsides than benefits and as such it is luckily not present in Oracle’s implementation. In Oracle there is full support for Inheritance but for what concerns abstract types as they are called in OOP there is a catch: Oracle calls Abstract Data Type (Objects, available from version 8i) the ability to create a type (as in OOP) without methods. This is not compliant with OOP, as Abstract Types in that context are types in which at least one method is only specified by signature, and are by default not instantiable. Yet it is possible to declare “incomplete types” in Oracle just declaring the type specification, with the method’s signatures and making them INSTANTIABLE . You can instantiate an object of that type, create object tables of it but you cannot call the unimplemented methods (ORA-04067). This is quite a different concept of Abstractness, but it’s compatible with the old ADTs without hindering the usage of this features by programmers. Inheritance is achieved by the use of the keyword UNDER for types which are NOT FINAL . The meaning of FINAL is the same as in Java, it means “not extendable” thus you cannot derive a subclass from a FINAL type.
• #5: Polymorphism Polymorphism is a wide and polymorphic concept. It refers to the ability of referring to some logic leaving to the internal mechanism of the language the actual implementation executed. Usually two different kinds of polymorphism are recognized: overriding and overloading , both can be available at runtime or compile time (with the first widely more useful than the second). Overriding allows one subtype to redefine a NOT FINAL method of one of its superclasses (through the use of OVERRIDING ), thus allowing the programmer to specialize the logic for the specific subclass. Overloading instead allows to have the same logic implemented in different ways for different input parameters. One example is the ability of operators like ‘+’ to sum up integers and floating point numbers. These concepts are often associated with the Dynamic Dispatch mechanism in which it is the object, at runtime, who chooses the fitting method to execute in a call. Following we see an example of overriding (Oracle developers already know very well the overloading, as procedures and packages allow a great deal of it) in the implementation of the method area() in the subclasses of MyShapeType .
• #6: see http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1545206281987 ) drop table MyShapeTab ; drop type MyCircleType; drop type MyRectangleType; drop type MyShapeType; 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; 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
• #7: The given example could be easily extended to represent hundreds of different shapes without changing (at least, changing explicitly) the storage structure of data. With a traditional Relational approach, the standard to represent different types is to create one table per type and then unite them as needed in every query. The query to find which shapes are of a given color would be, for example, very lengthy and would require to be changed every time a new type of shape is introduced. Without considering the problem of indexing: in that case the query would access one index for every type, instead with the OR (Object Relational) we have only one index. About this topic we see the syntactic difference between Relational and Object Relational tables. If we want to create said index on the shape’s color we have to be coherent with the point of view we choose: in our example create index shape_color_idx on MyShapeTab(color); would return, as expected, ORA-00904: "COLOR": invalid identifier . That’s because we created MyShapeTab as Relational table with an Objects as column, so the right way would be create index shape_color_idx on MyShapeTab(shape.color); If we stick to OR model we would have created the table like this: create table MyShapeTab2 of MyShapeType; so that the first create index would have worked.
• #8: Identity This is again an aspect of OOP too often overlooked as it’s available since the beginning of information technology: Objects are, to use the Relational jargon, Strong entities, that means they are uniquely identifiable, they are individuals, when they are manipulated it is a single place where the changes take place. In databases technology there is big behavioral difference between strong and weak entities, which is the existence of a primary key, but more generally speaking it is always possible to treat a strong entity as it was week (just disable the PK), on the contrary not always it is possible to make strong a weak entity. This translates in current programming languages to the difference between “by value” and “by reference” parameter passing, or an object and a pointer to that object. The importance of strong entities is so high that many of the most common programming languages nowadays do have only references to objects and the occurrence of “weakification” is usually marked by some special construct signaling the occurrence of a cloning operation. As stated before databases know very well this mechanism, but since the introduction of ADT the granularity of this composition relations changed, if before it went down from the Entity itself (Strong or weak depending on the presence of a PK) to one primitive type (weak), now it can stop in the middle, at a level which aggregates many columns together. Of course Primary Keys can be the answer, but it is not common in OOP to identify, or even to care for that, identity and uniqueness are given as tool from the very foundations of the metamodel. To provide such identity in an OR way Oracle has the REF. The REF is build upon the OID (Object IDentifier) which in turn can be generated and maintained by the engine or PK-based. In the first case the OID is a 16 bytes raw value uniquely generated and accurately kept unique through distributed or replicated environments (replicated environments are especially vulnerable to object “failures”, there are a set of guidelines on how to work on objects to make replication work correctly – we won’t talk about this), in the second case (pkOID) it has the same properties as the PK.
• #9: There are essentially three kinds of REFs: Scoped : the REF is pointing to an object on a specific table. It occupies as much as the OID does. Example: you have person objects references somewhere, but on the base you use them to represent both users and managers . You can leave it unspecified, and let the REF itself carry the information about which table is storing the object (unscoped REF), or specify in the definition of the REF which table stores the referenced object. Unscoped : the REF has two parts, the OID of the referenced objet and the OID of the object in which it is stored, another 16 bytes. Oracle recommends to use scoped REFs whenever possible, because they are stored more efficiently and guarantee a little better performance. Unscoped with ROWID hint : to the standard unscoped REF the ROWID of the referenced object is added, another 10 bytes. So in the worst of situations and unscoped with rowid ref will be 36 bytes long. In the relational theory the concept of a “pointer” is forbidden for the reason that the relational schema must be independent of the underlying physical organization of data, instead primary keys (the logic part) and indexes (taking care of the connection between model and physical layer) are provided. The presence of the ROWID can improve object navigation at the expense of more space utilization but is prone to disrupt the integrity of data when rows migrate, for whatever reasons, and as with any composition relation, if not enforced by constrains, the REF itself can be dangling, i.e. referring to a non-existent object on the referenced object table. For what concerns the ROWID hint, Oracle always checks if the ROWID points to the OID it has on the REF and if not it reverts to the OID index, for dangling REFs instead, there is nothing to do except the good practice of defining and enforcing a foreign key. To maintain REFs Oracle supplies the command ANALYZE … VALIDATE REF UPDATE SET DANGLING TO NULL, where the first part fixes the ROWID hints where needed.
• #15: Note: we include as the first parameter an instance of the same class by reference (NOCOPY), this is because the engine is by default applying the methods on a copy which is then returned back. The self keyword is like this in C++-like languages, and it has nothing to do with PHP’s self static scope qualifier.
• #16: Upcasting is automatic, downcasting to access subclass' methods behaves as expected, but upcasting doesn't work on overridden methods! I've tested this on Windows, 10.2.0.1.0 and 11.1.0.6.0.
• #17: Static You can declare static methods and call them prefixing the type name. They follow the same rules as static methods in all the other OO languages. Static properties are forbidden instead, as they pose a number of logic problems, in facts they are class’ properties as opposed to instance’ properties. Thus they should be stored in the dictionary along with the structure of the class. But what then about already stored instances when these static properties change? Imagine what to do when you retrieve two instances with two different values ... When static properties are needed then you may consider using a package to hold them. Indeed packages have the same properties as OOP classes with all static methods and fields.
• #18: Note: we include as the first parameter an instance of the same class by reference (NOCOPY), this is because the engine is by default applying the methods on a copy which is then returned back. The self keyword is like this in C++-like languages, and it has nothing to do with PHP’s self static scope qualifier.
• #22: Essentially there are two kinds of table in Oracle: Relational and Object Relational. (OR) CREATE TABLE object_relational AS TABLE OF <some_type> (R) CREATE TABLE relational (some_type <some_type>) When you define an OR table there are some important aspects to keep in mind. OID and Primary Keys Every object must have a unique identifier and if the developer does not specify it then Oracle assigns one 16 bytes long of its choosing. You can specify yourself which primary key constitutes the Object ID (called pkOID) and save some space on the table and on the OID indexes. 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 16bytes.
• #23: When you need to store a REF or pkREF you should always scope it unless the scattering of references on many entities is really a feature of your model. Ex: one Experiment is lead by Scientist which is in turn a Person. Also Technician-s and Employee-s are Person-s. Rather than store all the Person type instances in a Person OR table, we choose to store them separately, in Technician, Employee and Scientist Entities. The Experiment table, OR table for Experiment_o types, for the sci_leader field should look like CREATE TABLE Experiment OF Experiment_o ( sci_leader SCOPE IS Scientist … ); given Experiment_o type has a field sci_leader of type Person. If facts there is no purpose allowing references to Person-s which are not scientists. Note the fields are defined in the type while the storage properties are specified in the corresponding OR tables. This REF is efficiently stored and uses the fastest indexes. If conditions suggest those indexes won't be fast enough, you can choose CREATE TABLE Experiment OF Experiment_o ( sci_leader WITH ROWID … );
• #24: Check Constraints and Triggers There is full freedom of declaring constraints on object properties on OR tables as we do on R tables. The only limit on Check Constraints is they cannot use DEREF (the action of getting the actual object from its REF) or any nested table construct (plus standard limitations on check constraints). Triggers can be defined on object tables as well, but not on the storage table for nested tables.
• #26: The type_id, when queries are frequently considering this field (through the use of IS OF predicate), can be indexes, and being usually at very low cardinality is an excellent candidate for a bitmap index. Given an object its type_id is accessible through the SYS_TYPEID() function.
• #27: Imagine a real world hierarchy and the storage structure generated by such a metamodel! That would be a disaster, ending up with just one huge table per root type. This originates from the OO metamodel that considers inheritance an “is of” relation, so that a subtype is always substitutable in place of a supertype because the subtype is also all its supertypes. The way oracle represent hierarchies is not the only way, but is one simple and fast enough to be practical; another approach could be one table per type-slice, that is all the successive descendants properties of a type find place in a separate table. This produces smaller tables overall and smaller storage, but needs a number of joins to retrieve just one object. Impractical. Another approach is the LOB or XML approach in which the object is rendered through some middleman language (XML). This last approach would be really interesting to test in Oracle due to all its XML oriented features.
• #32: 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, but it has an 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. Nested tables, being tables, do have all the possible creation options of any table, for example they can be made Index Organized. If you consider the kind of model in which a nested table is used, a parent-child relation, in which the direction of navigation is from parent to child, we see that we are by design fetching for every parent row all the child rows on the nested table. If we can suppose the nested table has “short” rows, then this is pretty much the use case for IOT A limitation is that you cannot define foreign keys on nested table, or query directly from them (without using dirty tricks), although you can create indexes on them.
• #33: Type Evolution (Altering Types) The OR paradigm imposes many constraints on the horizon of possibilities, mainly because it follows a strict logic around type hierarchies. For example, once a type (its specification only! The body is totally encapsulated inside the type) has a dependent object it is non-droppable and non-replaceable. It is alterable though. In general you can (from v.9 on): add and drop attributes and methods: when adding an attribute to a type with subtypes consider that all the default constructors of the subtype will suffer a parameter shifting due to the implicit ordering of arguments because the superclass' attribute always precede the subclass' – another good reason to add user defined constructors. enlarge an attribute; modify final and instantiable predicates; modify nested collections' properties. But consider that as well as with tables types do have dependencies and before evolving a type is a good idea to apprehend its dependencies. This is usually the reason scaring DBAs from allowing OR features in their DB. Some operations are in facts more complicated and involve more steps, at first glance, than standard relational table maintenance. But if you consider the relations of data from the business point of view the amount of effort to change the model is the same, the only difference is that using the OR metamodel a greater part of that logic is transferred to the data model itself, thus making its change a bit more complex. Please refer to Database Application Developer's Guide - Object-Relational Features, c. 7 for an introduction on the topic.