News

Copyright © 2008-2019 Paula DiTallo

Tag Cloud



Decision Engineering: Object Model and Cache

Object Oriented Database Terminology and The Caché ®  Unified Data Architecture Approach: Overview

This is the first in a series of articles about designing a contemporary enterprise engineering decision application using a combination of technologies. The first phase of the solution will address the problem of capturing dissimilar data. This phase will utilize Intersystem's Cache as the primary storage facility for unstructured and structured data objects. Later in the series we will use Microsoft's Business Rule Engine (BRE) to illustrate how an object method can call end-user defined rules to rank the decision factors by assessing alternatives through quantitative means. Lastly, we will extrapolate the results into XML format, assessable through a web page.

Overall, I will spend very little time in this series discussing the nuts and bolts of relational data modeling and standard SQL--as it is my take that anyone interested in reading through this article is more interested in unifying the less conventional object data model with existing or more common enterprise technologies. If anyone requests me to under the blog-feed-back option, I’ll address relational approaches more thoroughly. In the instance of this overview, I have left out the similarities in storage options between the commercial and open source offerings of relational database management systems (RDBMSs), such as buffering, blocking, indexing, hashing, clustering, etc. For now, I’ll focus on what the object oriented database management system (OODBMS) storage options and terminology are, as you are likely to come across them directly or indirectly when working with a  Intersystem’s Caché ®  or db40 implementation.

In general, there are three kinds of collection types as they relate to disk storage and retrieval in the OODBMS world: keyed, ordered, and unordered. For these collection types, there are classes like:

  • Keyed : information derives part of its meaning from the key and can be located only by the key
  • Arrays: subscripts as numerical/sequenced keys to data stores within array
  • Hashed files: members stored/accessed by hash key
  • Dictionary files: collections of information.
  • Ordered: sequenced datasets
  • Unordered: equal part collection
  • Linked lists: pointer chain
  • Strings
  • Sets
  • Lists: element collection; related to application
  • Bag: related and non-related collections (for more on bags, click here)

All of this is great to know, but how do class definitions fit in with data storage types? To answer that we’d have to take a whirlwind tour in Mr. Peabody’s Wayback Machine to see. The first stop on the Wayback takes us to the indexed-file world and navigational databases (Xbases) where program or proprietary commands were executed to move pointers from one record to the next. Think of these models as having explicit, user-directed calls. In the earliest days of the RDBMS revolution, these explicit calls were still done, however not directly. The calls to the RDBMS itself were capable of interpreting more user-friendly queries (SQL) into the nuts and bolts of actually determining access paths. Today, we think of this process more as building query plans, optimization of query plans, and plan execution.  So, between the navigational access model and the relational model, the only real question answered is how the database is traversed.

Now, I’ll get to the heart of why class type definitions are so important to the discussion of data access in OODBMS implementations. Since class definitions overall answer the questions of how, what and when embedded in the definitions themselves, we can think of each object stored as a tiny database, with the methods for retrieval access and context already available. Cache  stores the meta-information, or definition of each class within a common repository (Cache class dictionary). The class dictionary is itself an object database, stored within Cache, whose contents can be accessed using objects. The concept of storing objects with relational access is described by Cache as the Unified Data Architecture (UDA) model.

As part of Caché’s UDA, Caché’ provides an Object Model (OM) which includes classes, properties, relationships, methods, object persistence, inheritance, polymorphism and swizzling.

Caché allows the developer to define objects through it’s workbench called Cache Studio, using traditional SQL DDL, through XML, or by defining them through an Object Oriented Programming Language (OOPL) like Java/C++/C#, etc.

As part of Caché’s UDA/OM, all persistent objects – no matter how created (e.g. Java, C++, Studio, etc.) automatically generate relational tables. Each object feature has a corresponding relational equivalent. So, for example an object class is equivalent to an RDBMS table’ a package of classes is equivalent to a schema; object properties are equivalent to table columns, etc.

For a brief walk-through on how the UDA/OM works, I am going to use the example of a Decision Support System (DSS) package used for engineering economic analysis. I’ll begin with the concept that all decisions, (in the context of this application), are tied to factors that contain various alternatives. From these alternatives, methods are applied to assess which alternatives rank closest to achieving the target goal(s).

Let’s start with an example of a class/object definition generated by using Caché  Studio.

Class DSS.Factor Extends %Persistent [ ClassType = persistent ]

{

  Index FactorIDX On Factor [type = bitmap];

  Property Name As %String (MAXLEN=100);

  Property Goal As %String(MAXLEN=10);

  Property Descr As %String (MAXLEN=300);

  Property Factor As %Integer;

  Property Rank As Alternative;

}

Later I will explain in detail the line: Index FactorIDX On Factor [type = bitmap] for now I will just say, think of it as a gateway binding to an RDBMS. The rest of the lines are straight forward, with the exception of the line: Property Rank As Alternative. This line represents the use of a user-defined data type called Rank.

The Alternative class is extended from Cache’s superclass called %SerialObject.  In essence the %SerialObject class converts itself to a string representation in order to embed itself in another container—in this case, Factor.

Class DSS.Alternative Extends %SerialObject [ClassType = serial]

{

  Property Result As %Integer(MINVAL=0,MAXVAL=100000);

  Property Target As %Integer(MINVAL=0,MAXVAL=100000);

  Property Status As %String;

}

 

In terms of SQL: SELECT * FROM Factor would yield returned rows similar to this:

Factor

Name

Descr

Rank_Result

 

Goal

Rank_Target

Rank_Status

 

 

 

 

1

AVAILABILITY: Landscape Blend Fill Mix A

Gravel and Sand Aggregate to minimize H2O run-off

1

 

Cost

10000

Accept

 

 

 

 

2

GO GREEN: Landscape Blend Fill Mix B

Organic Composition Aggregate to minimize H2O run-off

3

 

Cost

10000

Reject

 

 

 

 

 

Tuesday, March 18, 2008 3:52 PM

Feedback

No comments posted yet.


Post A Comment
Title:
Name:
Email:
Comment:
Verification: