Increased Object Type support within Data Modeler

Question

Hi,
This is a question mainly for the Data Modeler Development Team as well as the Tools group. First of all, the production version of Data Modeler 3.0 is very nice and the improvements in the DataTypes area over what was in EA1 are great. Thanks for adding the Domain support to the definition of Attributes and Parameters for Methods, that makes life much simpler and opens the door for a much wider range of object type modeling and ease of implementations since consistency can now be maintained much easier via Domains. Also the support for straightening of lines is awesome. This is the best implementation I have seen, even better that what we had in the Design Editor in Oracle Designer, kudos again to the team that built the diagrammer interfaces.
My question is, Going forward will Data Modeler continued to be enhanced to finally fully support Oracle Objects and the object relational (OR) model? I ask this because as users of Oracle's RDBMS, we do not have a tool that allows us to fully model and implement the features provided by the Server Group in the area of Object-Relational features and functionality. Oracle Designer had some OR modeling capability, but the end of life on product stopped all further development. One of the common excuses is there is no market demand for object - relational modeling. I would argue, that the lack of market demand for object - relational applications is because we have never have had a tool that fully supports Oracle's object - relational model. Nor do have we had a development tool that allows us to implement a fully developed Oracle Object - Relational model. The tools group stopped the development of Oracle Forms support for nested objects and collections. The LOV functionality for REF columns is pretty awesome, but we can't get to nested collections much less a nested collection of REFs.
So as a member of the end user community, we are stuck in this Catch 22. The Server Group continues to support and enhance the Object - Relational model, but the Tools and Modeling Groups haven't kept up with the tools to model or implement the functionality and features supported by the database. As a result we have a partially built set of tools that allows us to scratch the surface of the Object - Relational model but are not able to take full advantage of the powerful features of inheritance, inherited and extended collections, the ability to inherit and then extend methods, etc...
The Object - Relational model was introduced with Oracle8, 10g solved the type evolution problem which made production implementation of object types realistic. My question is; Is Data Modeler finally going to fully support Oracle's object - relational model? If we as the end user community finally get a tool that does fully support the OR model, we'll finally be able to model, build and deploy applications that will in turn create that market demand which is lacking for the object relational model.
Thanks in advance,
ScottK

Answer 1

Phil,
Yes, having the ability to include an attribute from an data type as part of the PK, UK and or index will be very, very nice. Doing that opens a number of doors on the design, modeling and implementation sides. It would allow us to model and then create a data type which has all the common attributes for housekeeping information within each entity -> table. This is something we tried to do with Designer but was pretty involved script wise. By being able to create specialized housekeeping datatypes and then using the 'add attribute' with the scripts provided with DM 3.0, it simplifies the model after the fact. Think about it, we'll be able to have a datatype with all the attributes for created on/by and modified on/by along will all the methods to populate those attributes (formerly columns), then we can include that datatype into the entity as an attribute called say, 'row_audit' with the datatype of 'common_'. Now in one pass we have the place to hold the information of who created and modified the row as well as the date and time along with all the code required to populate and maintain that information. Everything modeled, defined and written in one place. No more have to include or write the pl/sql across several different modules, rather the calls to the method, a constructor, are within the insert or update statements for that table. If we take that train of thought and extend it to include the housekeeping functions for relational primary keys, then we can create one datatype with the attribute and methods to create a single column primary key. Once that is pulled into an entity, defined as the part of the unique identifier and then pushed down as a primary key and resulting foreign keys. We have all the code to enforce and populate primary and foreign keys wrapped up in one datatype with its supporting method as a constructor. Think of the other possibilities that would be available once we can include nested attributes w/i keys and indexes. It makes some models and designs much simpler, more maintainable, more scalable (less code to execute), etc...
I have been thinking about this. I see ya'll have provided the options for IN, OUT, IN/OUT, COPY and NOCOPY as modifiers for the parameters on methods. We also have the option for COPY / NOCOPY in the constructor method for type. Will that be included?
Lastly, since the Server Group solved the type evolution problem, that coupled with the ability to include a datatype as a definition for column really opens the design doors. For example, by using a datatype of 'common_', as mentioned above, if the system requirement appears after the system is built for a the name of the source system to be included with the 'row_audit' information, we can modify the datatype 'common_' to include these new attributes and methods and then the ALTER TYPE syntax provided by the Server and Language groups to effectively extend all the tables to include this new system requirement. Till the Server group solved the type evolution problem, this wasn't possible and we had to write several 'alter table add column' scripts. This is all replaced with the ALTER TYPE... cascade data command now. Once DM 3.0 includes the ability to reference embedded attributes, design and modeling life will be great.
Thanks in advance,
ScottK