EntityClass and Attribute Components

Previous Next

There are several special component types that can be used to add further self-descriptive characteristics to an Item. These components do not represent Java primitives and are not strictly necessary; even armed with only the Java primitive components, one can develop full-featured applications. However these extra component types are very convenient and their use is encouraged. Many higher-level constructions use them. Both of them can be appended to a Cu just like the primitives, and they can be identified and parsed out of an Item in a Cu in the same way.

These component types are the essential elements in a particular optional higher-level usage of the basic ItemSpace model called the 'Entity-Attribute-Value' model. The EAV model extends the representational capability of the relational model, but it is easy to keep inside the bounds of the relational model if desired. Below we describe these component types in a model-independent way.

The underlying shape of the InfinityDB EAV model is similar to other models which differ primarily in name such as 'subject-verb-object' or 'subject-predicate-object', or 'object-property-value' models, or triples, or binary normalized relations or 'facts' or RDF or the entity-relation model. These models all can be considered as labeled directed graphs with multiple node types. However, InfinityDB is more general in that the kinds of Values is much richer.  

EntityClass Components

Here is how to use an EntityClass component: 
	EntityClass PERSON = new EntityClass(0); // 0 is the unique id for people
	..
	int personId = getPersonId(); // some source of id's
	..
	Cu cu = Cu.alloc().append(PERSON).append(personId)...;
In the above code, PERSON is considered to identify the set of Items in the database that have to do with people. It is analogous to the table name in an RDBMS. It will normally be the first component in the Item.

Why not call EntityClass components Table components? The reason is that EntityClass is part of an extended data model that encompasses the relational model in that it can have multi-value and other extended kinds of attributes, composite and heterogenous keys and values, and pairs of attributes called inverses. For now, think of an EntityClass as a table name, and for the time being we will go ahead and use it as such.

An EntityClass instance will normally be a static final in a given program, and its long constructor parameter identifies it uniquely. This long param is a permanent constant and serves as metadata, identifying a given Item as being part of a given set of related Items such as a table or a set and so on. Its constant parameter will never be changed once widely-distributed data that uses it has been persisted, although its name could be changed.  

Entity Components

The primitive component or components immediately following the EntityClass in the Item are called the Entity rather than 'Key'. If you want to stay in the relational model, just consider an Entity to be the same as a relational primary Key. An Entity can be more than one component long, representing the equivalent of a relational composite primary key.  

Attribute Components

Attribute components identify a 'column' of a 'table', in the relational sense. Here is the code: 
	Attribute CREDIT_CARD_NUMBER = new Attribute(29); // the param uniquely identifies this
	..
	Cu cu = Cu.alloc().append(PERSON).append(732).append(CREDIT_CARD_NUMBER).append(9193013132);
	..
	System.out.println(cu);
	// prints:
	// E0 732 A29 9193013132
As with EntityClass components, the constructor parameter uniquely identifies an Attribute and should not be changed once widely-distributed persisted data uses it. The code above creates a complete Item describing a particular Value of a particular Attribute of a particular person. The Value is 9193013132, and the person's id, or Entity, is 732. This is a standalone fact that can be inserted into or deleted from an ItemSpace on its own. If a set of similar Items are constructed having different Attributes but all with EntityClass PERSON and Entity 732, those Items correspond to a single row of a table, having the primary key 732.  

The 'Meta Twist'

Below is a table showing the Items in a simple database organized in the EAV-way. Each row of this table is an Item representing a Value of an Attribute. Note carefully again that the rows of this table are Items. Each cell of the table represents a single component of one Item. The InfinityDB engine actually compresses out common prefixes of adjacent Items, so this table leaves blank the cells that would not actually take space. The "..son, Paul" Entity is partially compressed, which is indicated by the "..". The ATTENDS Attribute is set-valued, as will be described in the next section. All of the Items logically starting with STUDENTS "Jenkins, Waldo", correspond to a single record in a traditional relational structure. So, there is a kind of 'rotation' or 'meta-twist' of the relational record from horizontal to vertical when represented this way. This meta-twisted view is similar to the display in the Item Editor ItemSpace browser, but it does not appear elsewhere.

EntityClass

Entity

Attribute

Value

STUDENTS

"Jenkins, Waldo"

STUDENT_ID

4323

 

 

ATTENDS

"Inorganic 101"

 

 

 

"Proteins 201"

 

"…son, Paul"

STUDENT_ID

2665

 

 

ATTENDS

"Organic 402"

 

 

 

"Lipid Synthesis 202"
 

Naming EntityClasses and Attributes

When EntityClasses are named, it is convenient for the name to identify a conceptual group of similar things the way a relational table name does, while Attribute names can indicate the kind of data stored as the Attribute's Values as well as its meaning, as we have shown. Attribute names map to relational columns, so you can use the same naming conventions. Unfortunately, Attribute names are global. You may want to name them like 'E_EMP_NO' or 'EMP_ID', where the initial 'E_' indicates the EMPLOYEE table to globalize them the way many RDBMS schemas do. One scheme is to make EntityClasses nouns, while Attributes are verbs. Then you have EntityClasses and Attributes like PERSON and HOLDS_CARD, or CREDIT_CARD and HELD_BY. Another simple solution is to define them within Java classes: Attribute E_EMP_NAME will be referred to as Employee.NAME.

Previous Next

Copyright © 2002-2005 Boiler Bay.