The Object-Relation-Kin Model Toward Relational Analysis and Design in General Object Oriented Languages Compl Yue Still Ableverse Platform Note: This is a draft paper for reviews, last updated 2007/05/05 Copyright © 2007 Ableverse Platform. All rights reserved. No part of this paper may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the copyright holder.

Abstract: The relational model is in use by many database systems. Object oriented technology is also widely used in database application development. But “object-relational impedance mismatch” was found between the two approaches. However, in the study behind this paper, the REAL mismatch is reevaluated, and the Object-Relational Mapping approach is found being actually mapping between the Network Model and the SQL interface. A new data model — the Object-Relation-Kin model is then derived from the entity-relationship model regarding the relational model, to better consolidate object technology and the relational model without defective mappings. Ableverse™ TheObjectBase as the DBMS and WebOfWeb as the blueprint project are showing a feasible solution in the Java™ programming language as realworld practices, on the basis of this new data model.

Table of Contents: 1. Introduction 1.1. Backgrounds 1.1.1. The Relational Model and the Entity-Relationship Model 1.1.2. Conventional Relational Databases and SQL 1.2. New Situations 1.2.1. Impedance Mismatch Problems and SQL's Limitations 1.2.2. Physical RAM Capacity Increased to Hold Mass Data 1.2.3. Developed Garbage Collection Technologies 1.2.4. More CPUs, More Cores, Sharing a Same Memory Space 1.3. Ideas with Object Oriented Database Systems 1.3.1. Adding Persistence Ability to Application Object Model 1.3.2. Unique Object Graph 1.3.3. Relational Data Traverse for Embedded DB Access 1.3.4. Hosting Based Interfacing for Distributed DB Access

2. Premised Object Orientation 2.1. Object Oriented Analysis and Design 2.2. The Java Programming Language 3. The Object-Relation-Kin Model 3.1. Data in Object Models: Exposed Properties and Encapsulated Fields 3.2. Multilevel Views of Data 3.3. Information Concerning Entities and Relationships (Level 1) 3.3.1. Entity and Relation Objects 3.3.1.1. Entity Object Inheritance 3.3.1.2. Relation Object Inheritance 3.3.2. Role in Relationship 3.3.3. Properties, Value and Type 3.3.4. Conceptual Information Structure 3.4. Information Structure (Level 2) 3.4.1. Object Identifiers 3.4.2. Data Fields Encapsulated by Objects 3.4.3. Entity and Relation Classes 3.5. Object Graph in Operational Memory (Level 4) 3.5.1. Relation Object Ties Other Objects with Tie Fields 3.5.1.1. Tie Field Name reflects Role 3.5.1.2. Behaviors of Tie Reference Object 3.5.2. Related Objects Reach Each Others through Kin Fields 3.5.2.1. Kin Field and Kin Set Field 3.5.2.2. Source Relation, Self Roles and Target Roles 3.5.2.3. Kin Reference 3.5.3. Derive 3NF Schema from E-R Schema, Direct Kin 3.6. Tabular Object States in Permanent Storage (Level 3) 3.7. Object Swapping and Swap Engine 3.7.1. Update Tables On Transaction Commit 3.7.2. Inflate Objects On Initial Access 4. Persistence System Design with ORK Model

4.1. Database Management System Supporting ORK Model 4.2. Create Domain Model with Persistent Objects 4.2.1. Design Domain Object Topography 4.2.2. Design Object Behaviors (Domain Logics) 4.2.2.1. Concern Persistence Behaviors 4.3. Provide Access to the System 4.3.1. Define and Implement Service Interfaces 4.3.1.1. Create Domain Objects 4.3.1.2. Find Domain Objects 4.3.1.2.1. Query Persistent Objects using SQL 4.3.1.2.2. More Query Mechanisms 4.3.1.3. Delete Domain Objects 4.3.1.4. Invoke Domain Object Methods 4.3.1.4.1. Methods Read Persistent Fields 4.3.1.4.2. Methods Write Persistent Fields 4.3.1.4.3. Methods Update Tie Fields 4.3.2. Host Foreign Task Agents with Domain Model Environment 4.3.2.1. Enable Task Agent Transmission 4.3.2.2. Impose Security Constraints 4.4. Design Data Analytical Applications using SQL 5. Object-Relation-Kin Diagram 6. Software Products for Reference

1. Introduction The Object-Relation-Kin Model was created due to studies on computer hardware and software evolution during the past decades, it is a derivation from the Entity-Relationship Model [ 3 , Chen, 1976 ] regarding the Relational Model [ 2 , Codd, 1970 ] , evolved to fit with mainstream computing hardware setups in today and near future, while to best consolidate the power of Relational technologies and Object technologies for efficient analysis, design and development of database systems. The Object-Relation-Kin Model is prototyped on the basis of the [ 11 , Java Programming Language ] . The whole efforts were focused on consolidating Relational technologies with Object technologies in General Purpose, Object Oriented programming languages, instead of the ambition to invent better programming languages, or ignoring the productivity and popularity of existing Object Oriented infrastructures.

1.1. Backgrounds 1.1.1. The Relational Model and the Entity-Relationship Model The Relational Model [ 2 , Codd, 1970 ] introduced the relation theory from mathematics to data management in computer science. The Entity-Relationship Model [ 3 , Chen, 1976 ] is based on set theory and relation theory, it has most of the advantages of the Relational Model, the Network Model and the Entity Set Model.

1.1.2. Conventional Relational Databases and SQL The dominant database management systems till now have been those so labeled Relational Database . Almost without exception, these database products (such as Oracle, IBM DB2, Microsoft SQL Server, PostgreSQL, MySQL) are based on a programming language called SQL. SQL arose with IBM System R, and later acquired its popularity. It had evolved beyond its original purpose to support object-relational database management systems and eventually became an ANSI/ISO standard. But SQL is commonly considered not fully portable as a fact.

1.2. New Situations 1.2.1. Impedance Mismatch Problems and SQL's Limitations In the early 1990s the differences between Object technologies and Relational technologies was labeled the objectrelational impedance mismatch [ 5 , Ambler, ORIM ] , citing a set of conceptual and technical difficulties which are often encountered when a relational database management system is being used by a program written in an objectoriented programming language or style. However, in The Third Manifesto (Foundation for Object/Relational Databases, 1998 / Foundation for Future Database Systems, 2000) [ 7 , C. J. Date and Hugh Darwen, TTM ] , SQL was cited to be responsible for the objectrelational impedance mismatch , instead of the relational model, since the typical lack of relational completeness, plus other significant failings with database management systems featuring SQL.

1.2.2. Physical RAM Capacity Increased to Hold Mass Data In 1981, referring to computer memory, Bill Gates said, "640K ought to be enough for anybody." But it has changed so much today. Servers with 2GB to 128GB of physical memory installed are very common in recent years. And there are no hard limit for the size to grow up to 16777216TB(17179869184GB) with 64-bit memory space. Even with 40-bit memory space for current PC architectures, the up limit is 1TB(1024GB), which is 1,677,721.6 times of 640K. Influenced by RAM limitation tradition, conventional database management systems use RAM merely as cache of data in secondary storages like hard-disks. This created no pain for SQL paradigm since the query based accessing nature of SQL, but caused serious inconvenience for Object paradigm. Because object oriented view on the whole system model was then blended with unavoidable logics mapping the cache (in-memory objects) between the data store (disk storages). Such mapping logics is called persistence logics — in contrary to business logics. After all, cache mechanism itself can't help being a source of complexity for the whole system. The increased RAM size finally set the unique stage for in-memory objects to perform their play.

1.2.3. Developed Garbage Collection Technologies With the modern Garbage Collection technologies (Weak and Soft references as for Java), runtime systems can determine whether in-memory objects are still in use, then only discard unused objects regarding memory supply and demand. They can help to implement more efficient and much simpler cache mechanisms.

1.2.4. More CPUs, More Cores, Sharing a Same Memory Space Not long ago, multi-CPU servers were barely affordable for small enterprises. Now the mainstream PCs for home are shipped with 2 cores (effectively 2 CPUs), 4 cores (effectively 4 CPUs) for professional personal computing. And server systems like SUN UltraSPARC T1 with 8 cores each with 4 threads (effectively 32 CPUs) are at quite affordable prices for small enterprises. The number of CPU cores are supposed to be doubled the next year (2008). All these CPU cores are sharing a same memory space in its architecture of today. This greatly increased the cost efficiency of in-memory data by making available to that much simultaneous processing power (CPU cores/threads).

1.3. Ideas with Object Oriented Database Systems 1.3.1. Adding Persistence Ability to Application Object Model Using exactly the same object model among the Database and its Applications is a key advantage of Object Oriented Databases over conventional Relational Databases. But things still get not pretty simplified when application objects have to write code to query / persist themselves or Data Access Objects still have to be implemented by object oriented applications. This is the common situation with current Object Oriented Database Management System (OODBMS)s, partially responsible for their less adoption than RDBMS. It is neither better with Object-Relational Mapping (ORM) mechanism. The idea comes to have persistence as an ability, that persistent object classes can declare to require it, then supplied/implemented by the database management system. This becomes quite possible when the database and the applications are coded in the same or compatible programming language and run in the same environment, with further helps by Automatic Code Generation technologies.

1.3.2. Unique Object Graph Loading object data from storage into memory is a costly course, so once an object has been loaded, it should not be discarded until necessary. And it's normally desirable that objects are unique across sequential accesses from the view of the applications. These are normally implemented by a cache , and by leveraging the modern garbage collection technologies, the cache can not only be simpler, but more adequate. With object uniqueness and the guarantee that objects still in use can not be discarded, we are able to safely combine persistent attributes and transient attributes into single objects. For the example of an object which encapsulating an IRC channel. With the uniqueness guarantee for this object, we can safely store the channel name/description and access rules (which are persistent and should survive server restarts) together with TCP/IP connections to channel subscribers (which are transient and are invalid after a server restart). But this can't be quite correct if the object is represented and accessed through a traditional cache, whereas it will possibly be discarded without hits after a period of time, and reconstructed on another fetch, even there are still subscribers to this IRC channel meanwhile. Atop a traditional cache, the application will have to design a separated runtime channel object, and maintain consistency/association among transient objects and persistent objects by hand

. The overall data model design will be simpler and more adequate when a unique object graph is shared by both persistent and transient aspects at runtime.

1.3.3. Relational Data Traverse for Embedded DB Access SQL itself can never just turn Object Oriented , with SQL as the primary access method, we will not be able to avoid the impedance mismatch [ 5 , Ambler, ORIM ] problems. SQL's nature is query, however when comes accessing an interconnected object graph, it is not all about query then. With Object Oriented thoughts, the natural way to access structured data is to traverse from one node to others related, rather than to query by criteria. A result of the Relational Model is that one Tuple can be related with other Tuple s by the existence of some Tuple s in a particular Relation serving this connective purpose. SQL reflects these connectivities by means of JOINs within query criteria, this approach fits in perfectly with the RAM Cache atop Disk Storage architecture, where applications are given no pointer to actual data, and can only specify them by logical criteria to perform data manipulations. In Object Oriented speak, this Relational result can be stated as: one Object can be related with other Objects by the existence of some Relation Objects in a particular Relation Class serving this connective purpose. But conventional Object Oriented data paradigm does not distinguish this sort of relationships from normal object references, thus resulted in the fact that conventional OODBMS choose to reflect such connectivities by just maintaining references in one object to others. In this way, they actually fall into the Network Model [ 3 , Chen, 1976 ] , other than the Relational Model in our question. In favor of the Relational Model as well as Object Oriented paradigm, we have to introduce the concept of Relation Class into the object space, whose object instances serve the function to represent relationships among other objects. With this defined, we will be able to maintain object relationships in the Relational way. That is, by manipulating objects of Relation Classes . And with helps from code generation technologies, direct references to related objects will be allowed to be declared by a persistent object, but transparently maintained by the relational engine of the DBMS. Finally traversing among persistent object graphs constructed in this way appears as natural as traversing Plain Old in-memory data structures matured before years. Further more, application logics can be implemented as persistent object behaviors.

1.3.4. Hosting Based Interfacing for Distributed DB Access By far interfacing (communication) between software components are based on invocations , the caller send a request to a target component, then wait that component to return a calculated response according to the predefined contracts. As most communications are synchronous, i.e. the caller pends to wait response from the target component, there are also asynchronous variants, normally called callback mechanism: The caller registers some callable routines to the target component, before sending asynchronous requests. And after an asynchronous request has been sent, the caller continues immediately to do other jobs at hand. The called component may have some results at a later time, then send the resulted information or notification via those callback routines previously registered. But all these approaches require the service contracts be previously defined and interpreted by the target component at runtime. It has to fore mostly expose those service functionalities as its callable interface/contract. The common thought of these approaches can be summarized as the idea of Invocation Based Interfacing , on contrary of the Hosting Based Interfacing idea proposed herein.

For communications between software components, by the idea of Hosting Based Interfacing , the requests sent between software components will no longer be pure data in fixed formats by interface/contract. Instead, they are in variable structure and each form an request command which maps to executable code supplied by the caller as well. XML is very capable of carrying request data in variable structures, and dynamic deployment technologies will aid the called components to fetch proper executable code to run on receipt of a command. Finally object technologies will help encapsulating these request commands into command objects to gain clearer design. These command objects are called Task Agents in Hosting Based Interfacing . For a database system, if distributed applications access the server through Task Agent objects, written in the same programming language as the DBMS, instead of sequential combinations of SQL commands, then you can reasonably expect: • • •

In design of Task Agent objects as part of an application, the database can be simply viewed as an embedded instance, then the benefits including unique object graph will be all available. Superior performance. Even possibly better than Stored Procedures if properly written (because in the DB native programming language other than SP specific languages). Power, flexibility, robustness as from the general purpose programming languages coding the DBMS itself.

2. Premised Object Orientation 2.1. Object Oriented Analysis and Design When comes to solving problems with computers, in traditional approaches, we first establish a form for data representation, in which elements of our problems can be represented as a model that computers are able to understand and process, then translate information from the real world to model data in such a form, and finally process the model using computers. However, for many complex problems in real world, it turns out very difficult to model and process all the elements in a single piece, since they consist of too many inter-related facts to be understood then brought to computers for processing, as a whole by human brains. Object Orientation is helpful to overcome this difficulty, by dividing every element in our problems into separated objects , each maintains its internal state data with behaviors and publishes some methods to be operated from outside. In this paper we emphasize the benefits by Object Orientation from general purpose Object Oriented designing/programming languages, so a key technique is to view problem elements as objects , and to concern their behaviors as well as the way they are represented by data. At the same time we have to be aware of the so called Anemic Domain Models ( [ 8 , Fowler, ADM ] ) in practices, without avoidance of this sort of OO models, we would gain overall OO advantages at a discount.

2.2. The Java Programming Language Many popular programming languages (such as Java, C++) support Object Oriented Programming (OOP). The Object-Relation-Kin model purposed in this paper is prototyped and initially developed on the basis of the [ 11 , Java Programming Language ] , an object-oriented programming language developed by Sun Microsystems. In the following sections, we shall use Java concepts over their equivalents in other programming languages if not stated otherwise. The reader should get familiar with [ 4 , OO Concepts in Java ] before continue reading rest of this paper. Note in the Java world, there is a widely adopted [ 12 , JavaBeans ] paradigm, stated in its official FAQ as: JavaBeans components, or Beans, are reusable software components that can be manipulated visually in a builder tool. Beans can be combined to create traditional applications, or their smaller web-

oriented brethren, applets. In addition, applets can be designed to work as reusable Beans. And many Java developers tend to write public reader/writer methods for all of the persistent fields in their persistent classes, to make these classes comply with the [ 12 , JavaBeans ] specification. Even worse, this is often encouraged (explicitly or implicitly) by persistence frameworks upon which developers build their persistence applications. But doing so often misleads the whole system design apt to manipulate those persistent states from outside the encapsulated objects, and usually produce unexpected Anemic Domain Models ( [ 8 , Fowler, ADM ] ) as a result. With the Object-Relation-Kin model purposed in this paper, we shall against the practice of exposing all persistent fields as bean-properties of persistent classes. Instead we write operational public methods (concerning business tasks) those encapsulate persistent fields as internal states.

3. The Object-Relation-Kin Model 3.1. Data in Object Models: Exposed Properties and Encapsulated Fields In a non-object oriented database system architecture, the database instance serves as a central repository for various applications to store and retrieve data. Data in a particular form ( the Data Model ) fully represents problem elements modeled in application programs. The DBMS and its applications all view the same piece of data in this same form. But in the study of an object oriented data model, since behaviors are used to provide information for outside of objects, instead of allowing direct data manipulation, we should be aware that data exposed as properties by an object are subtly different from states-backing data encapsulated as its fields. Although there are objects exposing some or all of their fields as properties (with reader and optional writer methods), many others do not. For example a BufferedInputStream object will never expose its internal buffer as properties. It is also possible for some objects to expose more properties than data fields they encapsulate, for example: public class PersonName { private String firstName, lastName; public String getFirstName() { return firstName; } public void setFirstName(String firstName) { this.firstName = firstName; } public String getLastname() { return lastName; } public void setLastName(String lastName) { this.lastName = lastName; } public String getFullName() { return firstName + " " + lastName; } }

A PersonName object stores 2 fields: firstName and lastName , and exposes them as 2 writable properties. But it exposes an extra property: fullName as well. Property fullName is readonly by itself but can be changed by writing the other 2 properties. Another similar example is a Person object, which may stores a birthDateTime field, while with simple calculations, can expose an age property as well as a birthday property from it, in addition.

3.2. Multilevel Views of Data In the study of a data model, we should identify the levels of logical views of data with which the model is concerned. As cited in [ 3 , Chen, 1976 ] , there can be 4 levels of logical views of data: 1. Information concerning entities and relationships which exist in our minds. 2. Information structure-organization of information in which entities and relationships are represented by data. 3. Access-path-independent data structure — the data structures which are not involved with search schemes, indexing schemes, etc. 4. Access-path-dependent data structure. As shown in [ 3 , Chen, 1976 ] , the Entity-Relationship model is mainly concerned with levels 2 and 3. And the relational model is mainly concerned with levels 3 and 2; the network model is mainly concerned with level 4. In the following sections, we shall develop the Object-Relation-Kin Model from the first level to the second level, then to level 4 for the operating environment of information under object orientation. At level 3 permanent storage of data is concerned with the ORK model, in much the same way as with the entity-relationship model and the relational model. Finally the mechanism of swap engine will be purposed to perform data translations between level 3 and level 4.

Fig. 1 . Analysis of data models using multiple levels of logical views

3.3. Information Concerning Entities and Relationships (Level 1) We can use the method purposed by the Entity-Relationship model ( [ 3 , Chen, 1976 ] ) to identify entities and relationships in our problem domain, and further view them as objects under object orientation.

3.3.1. Entity and Relation Objects We view entities as entity objects, while relationships as relation objects. Accordingly, we get entity sets as entity classes , and relationship sets as relation classes . Additionally we get object inheritance from object orientation.

3.3.1.1. Entity Object Inheritance It is easy to understand, that Cat and Dog are all Mammal , while Mammal and Bird are all Animal , this is inheritance among entity classes.

3.3.1.2. Relation Object Inheritance It is less obvious that relation classes have inheritance, too. For example, as shown in figure 3, WorkerAllocation and StorageAllocation are subclasses of relation class

ResourceAllocation .

3.3.2. Role in Relationship The role of an entity in a relationship is the function that it performs in the relationship. For example Husband and Wife are roles.

3.3.3. Properties, Value and Type At this level, we see attributes of entities and relationships as properties exposed by entity objects and relation objects. Every property has a value (with null as a special value), and every value can be viewed as an object and belongs to a particular type aka the value class. Such as Number , Height , Color and PersonName are value classes. Value classes also have inheritance, for example Integer is a subclass of Number . Figure 2 illustrates some properties exposed by class Employee . The age property has values as PersonAge objects. A value can be an aggregation of other values, for example a PersonName object is an aggregation of a FirstName object and a LastName object.

Fig. 2 . Properties exposed by class Employee Note that relation objects also have properties. Consider relation class WorkerAllocation (Figure 3). The percentageOfTime property , which is the portion of time a particular employee is committed to a particular project, is an property of relation class WorkerAllocation . It is neither a property of Employee nor a property of Project , since its meaning depends on both the employee and project involved. Similarly, the quotaSize property is a relation property of relation class StorageAllocation .

Fig. 3 . Properties exposed by relation class WorkerAllocation and StorageAllocation

3.3.4. Conceptual Information Structure Figure 4 illustrates in table form the information about entity objects of an entity class. Each row of values is related to the same entity object, and each column is related to a property. The ordering of rows and columns is insignificant.

Fig. 4 . Information about entity objects of an entity class (table form) Figure 5 illustrates information about relation objects of a relation class. Note that each row of values is related to a relation object which connects a group of entity objects, each having a specific role.

Fig. 5 . Information about relation objects of a relation class (table form) Note that Figures 4 and 2 (and also Figures 5 and 3) are different forms of the same information. The table form is used for easily relating to the relational model and the entity-relationship model.

3.4. Information Structure (Level 2) At level 2, we consider representations of conceptual objects. In the following sections, we shall see how entity objects , relation objects and their interconnections are represented.

3.4.1. Object Identifiers In the entity-relationship model ( [ 3 , Chen, 1976 ] ), entities and relationships are identified by primary keys . But this is inconvenient for an object management system. Under object orientation, we identify objects (whether entity objects or relation objects) with Object Identifiers . Every object managed by an object system is assigned a unique identifier, usually called Object ID or simply ID . And when persistent objects are distinguished from transient objects, their identifiers are sometimes called Persistent Object IDs . In practice, there are object systems built on top of conventional relational databases, they still identify tuples by primary keys, but in some of these systems primary keys are meaningless, generated values. These generated primary keys are called Surrogate Keys as described in [ 10 , Ambler, PK ] . Using object identifiers in the Object-Relation-Kin model is very similar to using surrogate keys in those object systems on top of conventional relational databases, except that object IDs are unique across the whole scope of an object management system while uniqueness of surrogate keys can only scope a local schema or even a single table. And by higher level of object orientation, the operational environment of an ORK system can overcome the disadvantages of surrogate keys described in [ 10 , Ambler, PK ] . With primary keys replaced with object IDs, we are also set free from telling foreign keys from normal properties. That is, if held by an object, the IDs of other objects are always used to reference those objects, instead of being its own properties. Unlike using natural properties to define keys, which is sometimes confusing.

3.4.2. Data Fields Encapsulated by Objects Fields are used to store encapsulated states of an object, while more or less properties can be exposed from these fields as discussed in previous sections. But not all fields of an object need to be stored permanently, the Java modifier transient well supported this purpose So a data field is a transient field if marked with the transient keyword. Other data fields are called persistent fields , whose values must be permanently stored in order to be restored surviving machine crashes or system restarts. Some transient fields can be reconstructed from other permanently stored fields, serving as cache to save runtime computations. For example the fullName field in the following PersonName implementation: public class PersonName { private String firstName, lastName; ...

}

private transient String fullName = null; public String getFullName() { if(fullName == null) fullName = firstName + " " + lastName; return fullName; }

Other transient fields are only meaningful to a single application execution context, and don't need restorations backed by permanent storages. For example a field holding a TCP socket connection to another host.

3.4.3. Entity and Relation Classes Entity objects correspond to entity tuples as with the entity-relationship model ( [ 3 , Chen, 1976 ] ), and entity classes correspond to entity relations there, with the little difference that an OID is added to each tuple and becomes the primary key. All persistent fields and their permanent values are the data representation of an entity object, while the full representation needs all transient fields and their values, plus all behaviors added. Relation objects correspond to relationship tuples as with the entity-relationship model ( [ 3 , Chen, 1976 ] ), and relation classes correspond to relationship relations there, with the little difference that an OID is added to each tuple and becomes the primary key, while OIDs of the entities involved in a relationship replace their primary keys. All persistent fields and their permanent values, plus all OIDs of involved entities are the data representation of a relation object, while the full representation needs all transient fields and their values, plus all behaviors added. Since entity objects are all identified by their own object IDs, we don't have correspondings to weak entity relation and weak relationship relation as with the entity-relationship model ( [ 3 , Chen, 1976 ] ). While the entity and relationship relations in the entity-relationship model are similar to 3NF relations, entity classes and relation classes act similarly. That as long as you start modeling with entities and relationships, instead of arbitrary relations, you don't need the decomposition (or transformation) approach for normalization of relations , which has to be performed with the relational model.

3.5. Object Graph in Operational Memory (Level 4) At level 4, we consider how entity objects and relation objects are accessed. We shall see that as being objects, their states are not supposed to be directly read or changed as pure data, such like with the SELECT , UPDATE or DELETE SQL commands . Instead, they want to be messaged through methods and properties they expose.

3.5.1. Relation Object Ties Other Objects with Tie Fields Each relationship ties 2 or more other objects together, the relation object representing it reflects this semantic by holding special fields called tie fields . For the example shown in Figure 6, there exists a Marriage relationship, which ties John and Jane together to be a couple. Where the Husband field ties Person John, and the Wife field ties Person Jane.

Fig. 6 . Ties and Kins concerning a Marriage relationship The tied object is the target object of a tie field , and the predicted common base class of all possible target objects is the tie field 's target type . For example, tie field husband of relation Marriage has its target type as class Person .

3.5.1.1. Tie Field Name reflects Role The name of a tie field is the role the tied object performs in the relationship. For example shown in Figure 7, worker and project are the roles defined with such 2 tie fields at relation class WorkerAllocation .

3.5.1.2. Behaviors of Tie Reference Object The value of a tie field is a tie reference object holding a pointer to the tied object. It has to be a separated object to carry behaviors neither belong to the tied object nor of the relation object itself.

Consider deletion of tied objects. A relation object may not allow some tied objects to be deleted upon certain conditions, or want to perform extra operations (e.g. delete/update itself or other objects) when a tied object is going to be deleted. These behaviors can only present at tie reference objects, and should be triggered by the DBMS at certain points. These behaviors should be overridable by applications. And upon successful deletion of an object, all tie fields holding tie reference to it should be cleared automatically, by the DBMS.

3.5.2. Related Objects Reach Each Others through Kin Fields Consider objects tied together by a relation object. Given a Marriage relationship shown in Figure 6, what would John say if asked: "Who is your spouse?" He'd probably answer: "My wife is Jane." rather than: "I'm involved in a marriage, where the wife is Jane." Take another example of WorkerAllocation relationships as shown in Figure 7. There is a workForProjects field at class Employee which is a set of pointers to all Project objects those ever tied by a WorkerAllocation relation object that also ties its owning Employee as well. And the haveWorkers field at class Project does the same vice versa.

Fig. 7 . Ties and Kins concerning WorkerAllocation relationships In many cases we would need these direct pointers from an object. If we want to know what projects an employee is involved in, then after get the Employee object, say r1 , we would like to get all projects from the workForProjects field (listing p1 and p2 ), rather than first obtain all WorkerAllocation objects tying r1 ( i.e. a1 and a3 ), then enumerate them to get the tied p1 and p2 projects. We call such a field kin field . It is owned by an object and holds one or multiple pointers to other objects related. The related objects are target objects of the kin field, and the predicted common base class of all target objects is the kin field's target type . Values of kin fields fully depend on values of tie fields of relevant relation objects, so it is possible that kin fields be maintained automatically according to relation objects. This automatic maintenance should be implemented by the DBMS that supports ORK model.

3.5.2.1. Kin Field and Kin Set Field Some kin fields may contain only one pointer, e.g. the spouse field, the father and mother field (shown in Figure 8) at class Person . Others may contain a set of pointers, e.g. the workForProjects field at class Employee and the haveWorkers field at class Project . When distinguished, a kin field with a single pointer is called a Kin Field while a kin field containing multiple pointers is called a Kin Set Field . But we generally call them kin fields when not strictly distinguished. Note in the relational model and the entity-relationship model, we consider multiplicities on every sides of a relationship, by examine all its participants at a time. There are One-One, One-Many and Many-Many binary relationships for example. But in the Object-Relation-Kin model, with the newly introduced Kin instrumental, we examine one kin of one participant at a time, to consider its multiplicity: • • •

A kin field can reach at most one related object. A kin set field can reach more than one related objects. Whether a kin field can point to no object, or whether a kin set field can be empty, is decided by behaviors of both its owner and its source relation.

3.5.2.2. Source Relation, Self Roles and Target Roles A kin field points to related objects (the target objects) of its owner, in context of a relation class, whose instances

establish the relationships. This relation class is called the kin field's source relation . For example shown in Figure 7, WorkerAllocation is the source relation of kin field workForProjects at class Employee , it is also the source relation of kin field haveWorkers at class Project . In the WorkerAllocation relation, Employee objects are only possible to perform the worker role, and Project objects are only possible to perform the project role. But objects of a participating class in a relation class is some times potential to perform different roles. Consider the children kin of class Person , which takes Parentage (a ternary relation class) as the source relation. We can see from Figure 8, both p1 and p2 can reach p3 through the children kin set, so the owner object of a children kin field can perform either the father role or the mother role in the source relation Parentage .

Fig. 8 . Kins of Person concerning Marriage and Parentage relationships For a kin field, the role(s) its owner object performs in the source relation are called its Self Roles , and the role(s) the target objects perform are called its Target Roles . Table 1 shows some example Kins, with Source Relations and Roles of them. Class Person

Kin (Set) Field Source Relation Self Role(s) Target Role(s) spouse

Marriage

husband wife

wife husband

Employee workForProjects WorkerAllocation worker

project

Project

haveWorkers

WorkerAllocation project

worker

Person

father

Parentage

child

father

Person

mother

Parentage

child

mother

Person

children

Parentage

father mother

child

Table.1. Example Kins, their Source Relations and Roles

3.5.2.3. Kin Reference Each pointer held by kin fields is a kin reference . We can see from Figure 7 and 8, that a kin reference actually traces through the source relation object, and references the object tied by another tie field. Although most times we care only the target objects, some times we also need the source relation objects, in order to obtain relation properties, or to make changes to the relationship. For example, when we want to know the percentageOfTime a worker is devoted to a project, we get it from the WorkerAllocation object. So a kin reference consists of 2 object references: one to the source relation object, and another to the target object. Values of kin fields and contents of kin set fields are just kin references, they should be maintained by the DBMS so applications only need to define kin fields then obtain kin references from them in order to traverse the persistent object graph. This means the DBMS should take care of kin references , when source relation objects are created/deleted/retied, the DBMS is responsible to identify relevant kin (set) fields , assign kin references to / clear kin fields , and add/remove kin references to/from kin set fields . When an object is restored from permanent storage, its kin (set) fields should also be properly filled by the DBMS.

3.5.3. Derive 3NF Schema from E-R Schema, Direct Kin So far our examples are all in Entity-Relationship schema, but 3NF schema is more compact when feasible, thus may be preferable in some cases. To derive the 3NF schema from a E-R schema, some source relations need to be compacted into their target classes. At the same time, the kin field at the original target class will be replaced with the corresponding tie field from the original relation class, while it's peer kin (set) fields will turn to be direct kins . A direct kin points to the same object as for both the source relation object and the target object. Such a compacted class is both the source relation and the target type of direct kins pointing to it. For example the PetOwnership relation class can be compacted into the Pet class, when one pet has just one owner, as shown in Figure 9.

Fig. 9 . Compacting PetOwnership Relation into Class Pet Note here the owner kin at the original Pet class is replaced with the owner tie at the original PetOwnership relation, and the pets kin set field at related class Person turns to be a direct kin after the compaction. Similarly, the Parentage relation class can be compacted into the Person class, since father and mother are all single kin fields of the original Person class. The resulted schema is shown in Figure 10.

Fig. 10 . Class Person with Compacted Parentage Relation Compared to Figure 8, here the father and mother kin at the original Person class is replaced with the father and mother tie at the original Parentage relation, and the children kin set field at related class Person turns to be a direct kin after the compaction.

3.6. Tabular Object States in Permanent Storage (Level 3) Permanent storages are key to durable object persistence. However, permanent storage devices like disks and tapes are far slower than random-access memory (RAM). This means as less data as possible should be stored in permanent storages, thus slow store/retrieve tasks could be limited to a minimum amount. We can see redundance of pointers and pointer sets for an in-memory object graph. Tie fields of relation objects hold pointers to the tied objects, this is enough to represent relationships between objects. But for convenience of object operations and reactions, we need kin fields holding direct pointers and pointer sets to related objects. While values of kin fields are fully dependent on values of tie fields at their source relation objects, we need just permanently store tie reference values, to have the whole object graph reconstructable. And tie reference values can be translated into object IDs of the referenced objects. So a persistent class, either an entity class or a relation class, can be stored in a tabular form. The table columns are all persistent fields, plus target object IDs in place of tie fields if for relation classes. Each table row stores the permanent states of an object.

3.7. Object Swapping and Swap Engine With memory page swapping, an operating system can run applications with total size bigger than all physical RAM installed for the machine. An application can safely assume RAM blocks allocated to it are right at hand upon access to them. Similarly, with object swapping, a DBMS can serve more objects than the system memory can hold. An object can safely assume itself and all its related objects are right there when behaves in memory. But unlike the linear mapping between RAM pages and spaces in swap devices, in-memory objects graph and their tabular states data in permanent storages need more sophisticated translations forth and back. The translations will be performed by the mechanism of swap engine . The swap engine is an abstract layer that bridges objects

representation in 2 different formats: as field values of in-memory objects or as scalar values stored in tables. Next we shall find proper occasions for the swap engine to perform object - table translations.

3.7.1. Update Tables On Transaction Commit Changes made to object states are grouped into transactions. A transaction is committed until all changes are successfully made, if anything went wrong before the commit point, all enclosed changes by the transaction should be canceled, that is, to rollback the transaction. Tables in permanent storages only store persistent states, so they don't need to be updated until transaction commits. Since permanent storage devices are slow, this improves performance. When a transaction is committed, the swap engine takes all updated objects enclosed by the transaction, and translates their changed states data into tabular format, then update tables in permanent storages with the tabular data. This process omits all kin references, and replaces all tie references with IDs of their target objects.

3.7.2. Inflate Objects On Initial Access Objects need to be loaded into RAM before behaving as objects. There are several scenarios a persistently existing object may not be in memory: 1. When the database instance is just started up, no object has been loaded into memory. 2. The database instance has loaded other objects but not this one, with no mandatory requirement for it from last start up. 3. The object had been loaded into memory and operated, but no application used it again for a period of time, and then other objects were swapped in, so it was swapped out. The first access to a not yet in-memory object is its initial access. Upon initial access, the swap engine translates tabular states data into the inflated format - objects graph in operational memory. During this process, the kins of the object, and tied objects if it is a relation object, have to be prepared as well, they must be reachable as the object is loaded. This means all tie fields and kin fields should be properly populated before an object can be considered fully loaded.

4. Persistence System Design with ORK Model So far we see the Object-Relation-Kin model only as a data model, but it is really for consolidation with object oriented approaches which emphasizes behaviors as well. In this chapter, a common paradigm of persistence system design is purposed, involving object topography design in ORK model, and behavior design for the object graph.

4.1. Database Management System Supporting ORK Model Unlike traditional database management systems, a DBMS supporting ORK model has to be more adaptive. It needs to inject much persistence related logics to its applications as appropriate, since things like values of kin fields must be automatically maintained, and such details must be transparent to applications. This means the DBMS must adapt itself to the whole lifecycle of persistence application development, and be collaborative with application code at runtime. In short, the DBMS does everything its applications aren't interested to implement, concerning the persistence data model and the semantics carried. And for points applications may or may not be interested, the DBMS should provide reasonable defaults, which applications may choose to override on their own. This is key to high productivity in persistence system development. In the following sections, we shall assume our design is based on a finished DBMS that well supports ORK model, so works to be done by the DBMS can be simply mentioned instead of going into implementation details.

4.2. Create Domain Model with Persistent Objects With Object-Relation-Kin model, we can create a Domain Model for our problems similar to the Domain Model described in [ 9 , Fowler, DL ] . But our domain model doesn't need mappers between tables and in-memory objects. Entity objects and relation objects in operational memory are our domain objects, we don't need to care how their states are stored in tabular storages, and how they are reconstructed in RAM. Our domain objects will be right at hand when they are needed, the translations between objects and tables are done transparently by swap engines from the DBMS that supports ORK model.

4.2.1. Design Domain Object Topography We concern data aspects of our system, through the following steps: 1. 2. 3. 4. 5.

Identify entities and relationships in our problem domain. Define entity classes for entities. Define relation classes for relationships. Define tie fields at relation classes, to tie target objects of the relationship. Define kin fields at entity classes, to perceive direct references to the related objects from an entity object. (And relation objects can be tied by other relation objects as well, so kin fields can also be defined at relation classes, in which case the relation class can somehow be viewed as an entity class so far as being a participant in another relationship). 6. Compact some relation classes into entity classes (derive 3NF schema from E-R schema) as appropriate. And change relevant kin fields into direct kins accordingly. 7. Start a new iteration from any of the previous steps. Then a web of interconnected objects can be constructed from the resulted class schema.

4.2.2. Design Object Behaviors (Domain Logics) Since references to related objects are right at hand via tie fields and kin fields, traversing among the object graph is rather straight forward. Methods of our domain objects can simply read/write their own encapsulated data fields, or consult related objects by invoking their methods which in turn read/write their fields as well. Persistent fields of our domain objects hold the local yet canonical data of our system, so our domain objects have access to the right data in place, some like Stored Procedures in a SQL database do. With all these conveniences, the domain logics (business logics) can be written purely as plain old methods of our domain objects.

4.2.2.1. Concern Persistence Behaviors A DBMS that supports ORK model should implement all persistence semantics declared by its applications. Annotations is a great way to simplify persistence declarations. Certain annotations can be used on domain objects to tell the DBMS which of their methods will read or write their persistent fields, or change participants of a relationship. Then the DBMS can allocate transactions to encounter these changes and update relevant permanent storages when the transactions commit. The DBMS should also provide override points where applications can replace default handling with their own logics, including: • • • •

Creation Checks: validate if a persistent object is legal to be created. Deletion Checks: validate if a persistent object has no dependent and is legal to be deleted. Cascading of Deletions: delete more other objects as a persistent object is to be deleted. Other Triggered Behaviors: those applications may be interested to override.

Domain objects should have custom behaviors coded overriding DBMS default handling those do not apply to our problems.

4.3. Provide Access to the System To be useful, a persistence system has to allow access from human users or other systems. Traditionally, such access is provided in ways including: • • •

Command Line Interface (CLI) Graphical User Interface (GUI) Application Programming Interface (API)

These mechanisms can be generally considered as kinds of Service Interfaces , those prompt expected input data, perform computations accordingly, then present the result as output data, all done in predefined orders. However as softwares become more complex, and more intensive integrations among components are needed, interfacing through predefined contracts appears too expensive than reasonable. In many cases it's more effective to accept foreign Task Agents and host their execution with a local environment. The task agents interact with the local environment to produce results for sending back to their originators.

4.3.1. Define and Implement Service Interfaces Go the traditional way, some user interfaces and/or APIs are designed. In responding to user actions or API invocations, some logics should be implemented to fulfill these requests, according to predefined contract/protocol specifications. Such logics are called Service Logics , in contrary to Domain Logics carried by methods of domain objects. They should affect the system by interacting with the domain model. They will need to create/find/delete domain objects and invoke their methods (domain logics).

4.3.1.1. Create Domain Objects Consider multiple database instances could run simultaneously within a single process (this can be quite true in an application server environment), it's necessary to associate the database instance with persistent objects under its management. So creating a domain object will involve instantiating a plain old object followed by putting it into a database instance. On reception of a new persistent object, the DBMS should trigger its creation validating logics that might fail the creation due to invalid conditions discovered. After successful creation of a new relation object, regarding values of its tie fields, appropriate kin references taking it as the source relation object should be set to proper kin fields, and added to proper kin set fields, automatically.

4.3.1.2. Find Domain Objects Domain objects should be able to be retrieved by their object identifiers. They should also be reachable from any of their related objects, by traversing from another node in the object graph containing them. However applications also need to find persistent objects by querying against their attributes. The DBMS has to support such requirements by providing sufficient query methods.

4.3.1.2.1. Query Persistent Objects using SQL Relational data is natural to be queried using SQL. The DBMS is supposed to support SQL queries against persistent object data. But here SQL queries mean exactly finding objects out by criteria , and DML (Data

Manipulation Language) commands those perform data updates do not apply. Regarding object orientation, inheritance should be honored as well in processing of SQL queries. So an object should be found if and only if its attributes match the criteria, regardless whether it belongs to the class being queried or any subclass of it.

4.3.1.2.2. More Query Mechanisms Other object query mechanisms such like Native Query introduced by [ 13 , db4objects ] and Language Integrated Query [ 14 , LINQ ] , could possibly be supported by the DBMS.

4.3.1.3. Delete Domain Objects The deletion operation may be implemented as an instance method of all domain objects, or as a method of the database instance handle. On deletion of a persistent object, the DBMS should trigger its deletion validating logics that might prevent the deletion due to invalid conditions discovered. The DBMS should also trigger reacting logics of all relation objects those tied this object as a target. Such logics may be implemented as a overridable method of the tie reference object held by a tie field of the relation object. In the reacting logics, exceptions could be thrown to prevent the deletion or cascaded deletions could be chained. After successful deletion of a persistent object, all tie fields tying it should be cleared, and all kin references pointing to it should be cleared from proper kin fields, and removed from proper kin set fields, automatically. After successful deletion of a relation object, all kin references taking it as the source relation object should be cleared from proper kin fields, and removed from proper kin set fields, automatically.

4.3.1.4. Invoke Domain Object Methods As the domain model encapsulates internal states of the system, public methods of domain objects define possible interactions the system is supposed to perform. Service logics invoke these methods to interact with certain domain objects. To automate transaction management, a domain object should be able to declare the persistence activities its methods would perform, so that the DBMS can implement their correct semantics regarding these declarations.

4.3.1.4.1. Methods Read Persistent Fields If a method reads the value of one or more of this object's persistent fields, it should be declared so by means of annotations or equivalents. Then the DBMS should trace into invocations to such a method, and encounter this object by its current transaction, so further ACID ensuring actions should admit this object has been read by this transaction.

4.3.1.4.2. Methods Write Persistent Fields If a method updates the value of one or more of this object's persistent fields, it should be declared so by means of annotations or equivalents. Then the DBMS should trace into invocations to such a method, and encounter this object by its current transaction, so further ACID ensuring actions should admit this object has been written by this transaction.

4.3.1.4.3. Methods Update Tie Fields To update a tie field of a relation object is effectively to change a participant in the relationship which the relation object stands for. If a method updates the target object of one or more of this object's tie fields, it should be declared so by means of annotations or equivalents. Then the DBMS should trace into invocations to such a method, and encounter this relation object by its current transaction, so further ACID ensuring actions should admit this relation object has been written by this transaction. At the same time, all objects tied by the changed relation object may have kin (set) fields taking this relation object as the source relation object, values (or contents) of these kin (set) fields should be updated accordingly as well, automatically.

4.3.2. Host Foreign Task Agents with Domain Model Environment Aside from user interfaces our system provides, consider other computer systems need access to our persistent system. Interoperations between software components even computer systems become more and more common and intensive nowadays. But this problem is being solved just with more flexible ways to define service interfaces by vast majority of computer system designs, such as Web Services and further Service Oriented Architectures . Service interfaces have to be predefined before other systems can test the interoperability out and actually use them. And since services logics are implemented by our system, changes of requirements will lead to redefinition of our service interfaces with cascaded changes of the service logics. This actually sets a limitation on the pace that the depending systems can evolve, and brings burdens for all teams to maintain the common service interface definitions in necessary collaboration. But we already defined the Domain Model , which pretty describes the nature of our system. Think again, we may already have defined many APIs simply wrap parts of our domain model, just because they (other systems) want to INVOKE such services. In fact we have another choice to host interactions with our system, that is to allow Task Agent objects sent by foreign systems to run locally in our environment with our domain model. In this way computations based on interactions with our domain objects can be carried by various task agents designed by their originating systems. So we will be able to focus on our domain model. And business logics with complex algorithms, otherwise implemented as transaction scripts by foreign systems, will boost dramatically in performance, since communication traffic (mostly over network) of intermediate result and parameter data of multi-round invocations goes away. This is Hosting Based Interfacing in contrary to the traditional Invocation Based Interfacing . In fact this is not a fresh new idea. Consider a SQL database and its distributed clients. SQL commands can be viewed as Task Agents sent by the clients, they happen to execute in environment of the database server. And SQL code interacts with the table schema and stored procedures there, similar to our domain model.

4.3.2.1. Enable Task Agent Transmission For scripting languages such as SQL, textual scripts can be both data and code. However for compiled languages such as Java and C++, objects have separated executable code to represent their logics. According to the languages our system intends to support, in which task agents can be designed to execute in our hosting environment, different transmission mechanisms will need to be designed. Task agents written in script languages can be sent directly in the script form. Compiled languages will need dynamic deployment and execution supports. But for all languages, if higher level of security is desired, that only signed code from trusted sources are accepted, dynamic deployment will be needed to support such features.

4.3.2.2. Impose Security Constraints To prevent hacking or malicious code from harming the system, security constraints should be imposed on executable code from externals. Especially for languages with general purpose runtime libraries potential to raise security risks. Modern language platforms like Java have built-in mechanisms for this purpose.

4.4. Design Data Analytical Applications using SQL Analytical applications normally require read-only access to source data, and mostly perform statistic intensive queries for analytics. So it's more appropriate for such applications using SQL to analysis object states data of the system.

5. Object-Relation-Kin Diagram

Fig. 11 . A Simple Object-Relation-Kin Diagram In this section we introduce a diagrammatic technique derived from the entity-relationship diagram: the ObjectRelation-Kin diagram. Figure 11 illustrates the relation class WorkerAllocation and the entity class Employee and Project using this diagrammatic technique. Each entity class is represented by a rectangular box, and each relation class is represented by a diamond-shaped box. Each tie field of a relation class is represented by an ellipse inside the diamond-shaped box of the relation class, with its name (aka the role of its tied object) stated. A solid line is drawn from the ellipse of the tie field to its target type, with a solid circle at the target type end. It may be surprising that kin (set) fields are represented at the source relation class, while they should reside in their owning classes when written in source code of Java or other programming languages. Well, a kin field is represented by one or more dashed arrow line from a tie in its self role list to another tie in its target role list, with the kin name drawn beside the line. A kin (set) field is owned by entity classes tied by ties in its self role list. A plural kin name implies a kin set field, while a singular kin name implies a kin field. Since a kin can have more than one self roles and more than one target roles, there can be multiple dashed arrow lines representing a single kin, all with the same kin name, as shown in Figure 13.

Fig. 12 . An Object-Relation-Kin Diagram for Analysis of Information in a Manufacturing Firm Figure 12 illustrates a more complete diagram of some entity classes and relation classes which might be of interest to a manufacturing company. Department , Employee , Project , Supplier , and Part are entity classes. Membership , WorkerAllocation , ManagerAppointment , PartSupplyment , and Assemblage are relation classes. The Assemblage relationship describes what subparts (and quantities) are needed in making superparts. The meaning of the other relation classes need not be explained. The Object-Relation-Kin diagram carries same semantics and implications as the Entity-Relationship diagram introduced in [ 3 , Chen, 1976 ] , with the addition of ties and kins.

Fig. 13 . An Object-Relation-Kin Diagram of Entity Person with Relationship Parentage and Marriage

6. Software Products for Reference To be really useful in practice, the ORK model has to be supported by concrete database management systems and implemented by realworld applications. Software products listed below do support or implement the Object-Relation-Kin model themselves, they can be used as tools for studies and researches around the ORK model. Their source code are also good references to understanding the ORK model in action. The High Performance OO DBMS: Ableverse TheObjectBase Ableverse TheObjectBase is a RAM targeted DBMS, implemented in the [ 11 , Java Programming Language ] . It implements a family of swap engines using various conventional SQL databases for permanent storage. See [ 15 , TheObjectBase ] for more information. The Concurrent Traverse Intensive Application: Web Of Web Web Of Web (WoW) is an open source project to create a new, Structural, Secure, Collaborative and Realtime Interactive media platform for the Web. WoW is developed and runs on the basis of Ableverse TheObjectBase. See [ 16 , WoW Project Home ] and [ 17 , WoW Demo Site ] for more information.

Acknowledgments: References and Suggested Readings: 1 . Compl Yue Still, Object-Relational Mapping The Fake: Speak of Relational Model In Your Favorite OO Languages http://www.ableverse.org/articles/fakeorm.pdf 2 . E. F. Codd, A Relational Model for Large Shared Data Banks. ACM (1970) http://www.acm.org/classics/nov95/toc.html 3 . P. Chen. The entity-relationship model: Toward a unified view of data. ACM TODS 1 (1976) http://doi.acm.org/10.1145/320434.320440 4 . SUN Microsystems, Object-Oriented Programming Concepts. The Java Tutorials http://java.sun.com/docs/books/tutorial/java/concepts/ 5 . Scott W. Ambler, The Object-Relational Impedance Mismatch http://www.agiledata.org/essays/impedanceMismatch.html 6 . Scott W. Ambler, Mapping Objects to Relational Databases: O/R Mapping In Detail http://www.agiledata.org/essays/mappingObjects.html 7 . C. J. Date and Hugh Darwen, The Third Manifesto http://thethirdmanifesto.com/ 8 . Martin Fowler, Anemic Domain Model http://www.martinfowler.com/bliki/AnemicDomainModel.html 9 . Martin Fowler, Domain Logic and SQL

http://www.martinfowler.com/articles/dblogic.html 10 . Scott W. Ambler, Choosing a Primary Key: Natural or Surrogate? http://www.agiledata.org/essays/keys.html 11 . SUN Microsystems, Java Programming Language http://java.sun.com 12 . JavaBeans http://java.sun.com/products/javabeans 13 . db4objects http://www.db4o.com 14 . Language INtegrated Query http://msdn.microsoft.com/netframework/future/linq/ 15 . Ableverse TheObjectBase http://tob.ableverse.org 16 . The WebOfWeb Project Site http://wow.dev.java.net 17 . The Official WoW Site http://www.webofweb.net

The Object-Relation-Kin Model

Database Management System Supporting ORK Model ... unavoidable logics mapping the cache (in-memory objects) between the data store (disk storages).

449KB Sizes 1 Downloads 213 Views

Recommend Documents

AlgebraSolidGeometry_E_3sec model 1 And The model answer.pdf ...
Whoops! There was a problem loading more pages. AlgebraSolidGeometry_E_3sec model 1 And The model answer.pdf. AlgebraSolidGeometry_E_3sec model ...

Supporting Model-to-Model Transformations: The VMT ...
can attach a Java program that realizes the actual transformation (referred to as a ..... M. Clavel, F. Durän, S. Eker, P. Lincoln, N. Marti-Oliet, J. Meseguer, and J.

The subspace Gaussian mixture model – a structured model for ...
Aug 7, 2010 - We call this a ... In HMM-GMM based speech recognition (see [11] for review), we turn the .... of the work described here has been published in conference .... ize the SGMM system; we do this in such a way that all the states' ...

The 123PRSP Model
s: Average savings rate ... where R is the nominal exchange rate and P; the world price of .... cent, it also has one of the highest prevalence rates of W A D S .

Introducing the HPGENSELECT Procedure: Model ... - SAS Support
cluster of machines that distribute the data and the computations. ... PROC HPGENSELECT is a high-performance analytical procedure, which means that you ...

Model of the Atom.pdf
There was a problem previewing this document. Retrying... Download. Connect more apps. ... Model of the Atom.pdf. Model of the Atom.pdf. Open. Extract.

The Contextual-probability Model
With the introduction of corporate networks for management systems support ... of mapping of document logical structure to different models of databases and ...

The New Keynesian Model
showed that by putting money in the utility function could add a money demand curve to the model, but if the central bank conducted ... However, their utility is over aggregate consumption. Firms, since they are ..... forecasts), the coecient on inat

The core model induction
Mar 29, 2009 - Introduction. Canonical models. Previous work. Analysis of hod. More details. What is core model induction? Core model induction is a technique for evaluating lower bounds of consistency strengths of various combinatorial statements. I

The Fluid Events Model
The data from one person was dropped for failing to follow the instructions, leaving data for thirty-four people. The Binary Prediction data set contained 20,400 valid observations with a switch rate of .227. The rate at which the different actions w

The shared circuits model
Printed in the United States of America doi: 10.1017/ ..... action and similar performance, no translation is needed. But things ..... The advance from cooperation plus deceptive copying ..... you reach to pick up the ringing phone, your act and my.

The local Solow growth model
By local, we refer to the idea that a Solow model applies to each country, ... F G. , the analogous savings rate for human capital, and the log of (n. G##), where n.

Why the Standard Model
Available online 29 September 2007. Abstract ... The classification in the first step shows that the solutions fall in two classes. ... There are three real forms: unitary: Mk(C), orthogonal: Mk(R), symplectic: Ma(H) where H is the skew field of.

Model Questions
The entrance test for admission to Master's Degree in Hospital Management is ... After successive discounts of 10% and 8% have been granted the net price of ...

The Process Model of Roleplaying
Exploration of an Entity of the Shared Imagined Space. ○. Exploring the many-fold interactions a single entity has with others. ○ Exploration of a Concept through the Shared Imagined Space. ○. Exploring a concept through its expressions in the

4. Model Design of Weather Monitoring Model
model are AVHRR – LAC (Advanced Very. High Resolution Radiometer – Local Area. Coverage) type. Description about it could be seen in chapter 2.2.3. Actually, it has spatial resolution is 1,1 x 1,1 kilometers square and temporal resolution is one