0. Intended Use
1. Basic Concepts
A convergence of view between the object technology and relational databasecommunities has recently emerged. All parties are agreed that object orientedfeatures outlined in The Object-Oriented Database System Manifesto [1]are highly desirable. The X3H2 Database Standards Committee has releaseda draft SQL3 Specification that incorporates a number of object-orientedfeatures [see SQL3 entries in this matrix]. The relational database communitypublished the Third-Generation Database System Manifesto [2] to specifythree tenets that new database technologies must support to be generallyuseful.
The first tenet specifies that "third generation DBMSs will providesupport for richer object structures and rules," a view that is consistentwith the object database community. The second tenet specifies that "thirdgeneration DBMSs must subsume second generation DBMSs." In particular,the authors note that second generation systems (relational databases)improved over first generation systems (CODASYL and hierarchical databases)by providing non-procedural access (SQL) and data independence (ANSI/X3/SPARCThree Schema Architecture [3]). The third tenet requires that third generationDBMSs be open to other subsystems. Friendly access from many programminglanguages, tools, and applications running on a variety of operating systemsand hardware is mandatory.
Matisse claims to support language independence, an open systems environment,and multiple data models, including a complete object model, and to meetthe requirements of both the Object-Oriented Database System Manifestoand the Third Generation Database System Manifesto. [4]
2. Objects
In April, 1993, at a public meeting of experts in object technologystandards and SQL3 language development, the following tenets were proposedas fundamental to the object paradigm. [5]
T1. A first class object has unique, immutable identity within its scopein a distributed environment.
This is essential for pointer navigation in a database, for maintenanceof the referential integrity of the database without a lot of extra overheaddoing special checking, for allowing multiple unique objects with the sameattribute values, and for many important analysis and design considerations.Khoshafian et al. [6] outline the many technical advantages of object identity.
T.2. A first class object always knows what type(s) it is.
Several problems are associated with an object not knowing what typeit is. For example, if persistent objects lose knowledge of their typewhen read from the database into memory, this affects the association ofproper behavior with the object.
T.3 A instance of a subtype is always an instance of its supertype.
This is a major feature in most commercial object-oriented productsbecause it allows type safe utilization of supertype instances anywherein a program where the subtype is expected.
T.4. First class links occur only between first class objects.
Support of inverse links on first class links guarantees the referentialintegrity of a database without the additional overhead of stored procedures.
The Matisse Object Model supports these fundamental tenets with thecaveat that Matisse objects can only be of one type. All Matisse objectsare first class objects including instances, class schemas, and the Matissemetamodel (all are stored as objects in the database).
The structure and behavior of Matisse objects flows from the Matissemetamodel. The user can modify the metamodel, which changes the Matisseobject model. The metamodel is a template for creation of the class schema.Class schema objects are, in turn, templates for creation of instancesof a class.
Matisse is a completely versioned database supporting copy semantics.A change to an object always results in creation of a new version of theobject without altering previous versions or the object identifier (OID)of the object. Versioning is orthogonal to object model considerationsand is handled transparently by the Matisse Server Engine.
2.1 Operations
The Matisse metamodel (the class CLASS) has methods and messages asattributes. The interface to a class consists of methods (or functions)attached to the class and messages which are used to invoke the methods.
2.2 requests
A message is a request for execution of a method.
2.3 messages
Messages are part of the Matisse metamodel and are used to invoke operations(methods).
2.4 specification of behavioral semantics
Objects stored on disk contain a reference to methods and messages whichinvoke them. The object code of a method is stored on the client workstationand executes on the client (except for certain operations which will occuron the server for performance optimization). Operations are function callswhich execute on the client. Method object code can be generated from anylanguage.
Referential integrity is automatically maintained by the database byautomatic support of inverse linkages between objects. Attributes, relationships,and classes all have user specified constraints. In addition, since Matissesupports pre- and post-condition triggers on all attributes and relationships,any computable user constraint can be implemented.
2.5 methods
Methods are part of the Matisse metamodel. They are functions attachedto objects which are invoked by messages.
2.6 state
The state of the Matisse metamodel is represented by values stored inthe objects which represent the metamodel. The state of the class schemais represented by the values stored in the objects which represent thedatabase schema. The state of an instance is represented by values storedin the instance. Values may be literals or OIDs that serve as pointersto related objects.
All objects (metamodel objects, class schema, and instances) are storedon disk in buckets, which are discrete units of transfer of informationfrom client to server. Bucket size can be optimized by the user for applicationperformance.
The state of the database is determined by logical time, which incrementsat commit time of each transaction. The database may be viewed from anylogical time specified by the user. The user sees all objects which existedat the specified logical time in the state as it existed at that logicaltime. This includes metamodel objects and class schema objects, as wellas instances.
2.7 object lifetime
The designers of Matisse felt that garbage collection was inappropriatefor commercial production databases. Version collection occurs at the discretionof the user. If all version collection is done immediately, the databaseoperates like current database systems which have no inherent knowledgeof object history.
Typically, version collection is done on a user-specified, periodicbasis after execution of a "save time" function which flags ahistorical logical time as a view of the database that should not be collected.Reporting or on-line backup can be done without locking by executing readson the "save time" view of the database. If reporting or backupis done at low priority, this has negligible effect on performance of productiontransaction processing. When historical versions are no longer needed,they may be version collected at the discretion of the user.
Matisse is designed to retain knowledge of all historical states ofthe database through systematic archival of version collected objects.
2.8 behavior/state grouping
2.9 communication model
2.10 events
2.11 transition rules
3. Binding
Binding through inheritance
Binding is supported in a straightforward manner. Functions are boundto objects through the inheritance hierarchy. Subclasses consist of allattributes, relationships, messages, and methods of the superclasses plusthose additionally specified by the user. Multiple inheritance is supportedand all instances of a subclass are instances of the superclasses.
Matisse does not allow name conflicts on attributes and relationships.Methods may be overloaded. In a multiple inheritance hierarchy, invocationof methods occurs in a left first, depth first manner which is determinedby the way the user specifies the class hierarchy.
The Matisse class hierarchy is independent of any language hierarchy.Typically, a user develops an application hierarchy that consists of persistenceand non-persistent objects. The persistence objects are mapped into theMatisse database by calls to the Matisse API (a set of C function calls).
Binding through constraints and triggers
Using the API requires the application programmer to translate objectsinto the database. A set of classes could be created to support persistentC++ or Smalltalk transparently to the programmer.
The overhead of using the API is compensated for by the gain in functionalitysupported by the database. Matisse supports constraints on attributes andrelationships, as well as pre- and post-conditions on any changes to attributesand relationships. The database will always look for these constraintsand triggers when processing. It the user has not specified any, thereis virtually no cost. As an implementation of the notion of "storedprocedures", this kind of binding is orthogonal to the inheritancehierarchy.
4. Polymorphism
Polymorphism is supported by the binding mechanism described in theMatisse entry under 3. Binding
5. Encapsulation
Encapsulation is supported through the use of the object paradigm. TheMatisse API allows execution of methods. Attributes may be publicly accessedthrough the API as in C++, but can be hidden from direct access by theuser through constraints as in Smalltalk.
As in all database systems, encapsulation is violated by indexes thatallow rapid scan of the database for selection of sets of objects of interest.Matisse allows any attribute of any object to be an "entry point"or index. By default, the attribute value is the symbolic index to theOID of the object. However, the user can create any "entry point"function and sophisticated algorithms can be used to build intelligentindexes. Encapsulation could be violated by an image query, for example.One could provide a drawing or mug shot and the database would return suspects,or a picture of an airplane and the database could return the locationof all similar airplanes in recent satellite photos.
6. Identity, Equality, Copy
Matisse supports the principle that first class objects are identicalif their OIDs are equal. They are equal if their attributes have the samevalues.
The following caveats apply:
Matisse supports media fault tolerance through object replication acrossmultiple disk drives. In this case, replicated objects are identical.
On the other hand, if the user makes a copy of an object, it will receivea new OID but retain the same attribute values. In this case there is equality,but not identity.
7. Types and Classes
In Matisse, as in many object systems, a class is an implementationof a type. Attributes are typed as in C or C++.
Classes, including the metaclass and its associated objects are "firstclass objects" in Matisse. They are physically stored as objects onthe server and may be modified like any other object. This allows supportof on-line schema evolution.
The structure and function of objects is determined by the metaclass.The user may modify the metaclass to support specialized data models andfunctionality. For example, the metaclass Attribute can be modified toallow read and write to data in an external relational database. This allowsany attribute of any object in the system to be specified as residing inan external database. When an object is accessed, such attributes appearas part of the object transparently to the user.
8. Inheritance and Delegation
Matisse supports standard "specialization" inheritance asimplemented in C++ or Smalltalk and described in the Matisse entry under3. Binding.
Delegation can be implemented in Matisse by providing a method, trigger,or constraint, that invokes any other method(s) or function(s). In addition,there are "universal methods" that are independent of the inheritancehierarchy. These can be invoked by any method or function attached to thedatabase or from the application through the Matisse API.
9. Noteworthy Objects
9.1 relationships
The Matisse metamodel specifies the structure of relationships. Inverserelationships are automatically supported. Referential integrity is guaranteedby enforcing the simple rule: "No object can be deleted until itslinks to other objects are deleted."
The metaclass supports specification of cardinality of a relationship.It also includes user-specified triggers that fire before and after addingor deleting a link.
At the metaclass level, a relationship is a class that is physicallystored as a first class object. At the class level, a relationship is anobject with instantiated values of the attributes that are specified atthe metaclass level. An the instance level, a relationship is physicallystored as an OID(s) of a related object(s).
9.2. attributes
At the metaclass level, Attribute is an object that is part of the metaclass.Its attributes are external name, default value, constraint function, indexfunction, pre-modification trigger, and post-modification trigger. Thevalues of attributes of Attribute are stored as part of the binary objectwhich represents an instance of Attribute.
An instance of Attribute can be associated with an instance of the metaclassClass. The instance of Class, (i.e. a class, like Person or Company) isstored as a binary object with links to a binary instance of Attribute(i.e. Name or Address).
An instance of Person is stored as a binary object. Attribute valuesare embedded in the binary object at this level.
9.3 literals
Attributes values in Matisse can be literals or sets of OIDs. The usercan define constraints on literals which will be enforced by the database.Literals include the following types:
Characters
ASCII characters
Arrays
Lists
Floating point numbers
Lists of floating point numbers
Double precision numbers
Lists of double precision numbers
Strings
ASCII strings
String arrays
ASCII string arrays
String lists
ASCII string lists
Arrays of 8, 16, and 32 bit words
9.4 containment
Complex structures can be embedded in a Matisse object as a literalvalue. For relationships, OIDs are specified and the linked objects arenot contained in the sense that deletion and other actions are not automaticallypropagated unless the user specifies an appropriate trigger.
9.5 aggregates
Matisse literals support aggregates as lists and arrays. Class relationshipssupport a list of OIDs specifying links to other objects. Any type of aggregatecan be supported, but the user must specify the behavior by supplying theappropriate links and triggers.
9.6 other
The Matisse metamodel consists of a set of objects that make up themetaclass. Class schemas are objects in their own right.
10. Extensibility
The Matisse object model is extensible by the user. Schema evolutionis supported, with the constraint that database consistency will be enforcedby the object manager. This includes the metamodel which may be extendedby the user.
10.1 dynamic
In Matisse, all extensibility is dynamic. It must be accomplished withthe database live. Class schemas and the metamodel may be changed at theusers convenience. The object manager will enforce consistency of datain the database and provide appropriate error messages if the user triesto do anything that will render data inconsistent.
Security restrictions normal prevent users from gratuitously changingschemas, particularly the metaschema. Nevertheless, in some applicationsit is important to be able to dynamically create, destroy, and update schemas,as well as object instances, even in multiuser environments. Matisse supportsthis.
Matisse maintains versions of all objects, including schemas. Userscan see a consistent view of any historical state of the database.
10.2 metaclasses/metaobject protocol
Matisse supports the concepts of metaclass and metaobject protocol.[7]
10.3 introspection
All objects in Matisse have a unique immutable identifier and know whattype they are. This includes metaclasses, class schemas, and object instances.
11. Object Languages
The next release of Matisse with support ANSI SQL92 with object extensions.The evolving SQL3 specification will be fully supported as it stabilizes.
The Matisse API is a set of C library functions that can be bound intoany language that supports an external C function call. The API supportsall features of the database. Thus any language can bind to Matisse.
12. Semantics of Base Classes (+type constructors)
The semantics of Matisse classes are specified by the metamodel. Thedynamic features of Matisse allow the user to modify the metamodel andmold the semantics of the database to application requirements.
13. Background and References
[1] Atkinson, M. et al. The Object-Oriented Database Systems Manifesto.In Deductive and Object-Oriented Databases. Elsevier Science Publishers,1990.
[2] Committee for Advanced DBMS Function (Stonebraker, M., et al.).Third Generation Database System Manifesto. ACM SIGMOD Record, Sep 1990.
[3] Tischritzis, Dennis, Klug, Anthony . The ANSI/X3/SPARC DBMS FrameworkReport of the Study Group on Database Management. Information Systems3:173-191, 1978.
[4] LeLong, Philippe, Moller, Pierre. MATISSE Product Overview.Intellitic International, Inc. 1993.
[5] Sutherland, Jeff. Dialogue on Objects and SQL3, Meeting Notes, 14-16April 1993, Palo Alto, CA. X3H7-93-057.
[6] Khoshafian, Setrag N., Copeland, George P. Object Identity. In ReadingsIn Object-Oriented Database Systems. Zdonik, S.B., Maier, D. (Eds.)San Mateo, Morgan Kaufmann, 1990.
[7] Kiczales, G., des Rivieres, J., and Bobrow, D. The Art of theMetaobject Protocol. Cambridge: MIT Press, 1991.
