The Boston Object-Role Modeling Metamodel — Pt3 — Entity Types
Framework for a Knowledge Graph / Index
An Entity Type is one of the atomic building blocks of a Knowledge Index or Knowledge Graph. We recognise them as the Entities of Entity-Relationship Diagrams and the Node Types of Property Graph Schema for graph databases.
An Entity Type is nothing without its associated Value Types.
If I walked up to you and said, “Employee”, a natural reaction would be “Which Employee?”, and from there we draw on the Value Types that identify the employee, “Jane Smith”.
For instance, the Entity Type above is shown to be uniquely identified by Values of its related Value Type, Employee_Id, (.Id) being a shortcut notation in Object-Role Modeling to indicate such an association. Employee, Jane Smith, may be identified by the Employee_Id, 123.
If we were to speak of the employee, “Jane Smith”, we might identify Jane Smith by the Entity Type, Employee, with associated Value Types, Employee_Id, First Name and Last Name, as below:
The Boston Object-Role Modeling metamodel may itself be represented as an Object-Role Model, with an Entity Type/Objectified Fact Type, MetaModelEntityType representing Entity Types within Object-Role Models.
Entity Types within the Boston Object-Role Modeling metamodel appear as such:
An Entity Type within the metamodel is a combination of the Model that the Entity Type belongs to, and the Symbol (Concept) of the Entity Type.
For instance, a Model with Model_Id, 123, and a Concept with Symbol, ‘Employee’, represents the Entity Type, Employee, within the Model.
NB Because we are dealing with an ostensible First-Order Logic with Object-Role Modeling, we can use the actual Name/Symbol of the Entity Type as its identifier (along with ModelId) because it is not going to be confused with a Fact Type, or Role Constraint that must have a unique name within the model, each of those also being a subtype of the MeetaModelModelDictionary.
NB A full treatise of Concepts, Symbols and the Models they belong to can be found in an earlier article I wrote, at the start of this series on the Boston Object-Role Modeling metamodel: [here].
We use the word, Symbol, to represent concepts within the Boston metamodel, because in as mcuh as you utnredsnad taht the wrods in the rset of tihs sntenece roesvle as in your mind as smboyls, palese cdsndior taht as you raed it and utnredsnad it…yuur biran palys its gmae, not a tcirk, but a gmae of dbsnemilisg this stnecnce itno wrods taht in yuor barin repersnet a concept.
E.g. Normally within a first-order logic, we may have a single-character symbol to represent the set of all employees, E, a set variable. What we are saying within the Boston Object-Role Modeling metamodel, is that we use strings, e.g. ‘Employee’, to represent a set variable in first-order logic. And within our mind, words such as, Employee, actually resolve as symbols. Their meaning is only derived to us by way of their context in relation to the values of Value Types, and as described above.
Because words/Symbols/Concepts/Entity-Types, such as, ‘Mission’, can have different meanings depending on their context, in the Boston metamodel, this context is a combination of the Model within which the symbol is used, AND the values of Value Types associated with the symbol/Entity-Type.
From that position we can look at the Value Types/Fact Types associated eith MetaModelEntityType:
- EntityTypeName -Is redundant, because it is the same as the Symbol of the Entity Type;
- ReferenceMode — E.g. ‘.Id’, being shortcut for the Reference Scheme for the Entity Type, Employee, being Employee has ONE Employee_Id, Employee_Id is for ONE Employee.
- PreferredIdentifierRCId — The unique Symbol for the Role Constraint that provides the Reference Schem for the Entity Type.
- GUID — A unique GUID/UUID that identifies an Entity Type universally;
- Is Personal — As when an Entity Type represents a person (e.g. Employee);
- Is Derived — If Entities (instances) of the Entity Type are derived in some manner (say within a database, as in a ‘view’);
- Derivation Text — The text that defines the rules that derive Entities of the Entity Type if the Entity Type is defined as ‘Is Derived’;
- Is Absorbed — Used for subtyping, to absorb attributes/columns/columns of a subtype into its supertype;
- Is Independent— The Entity Type need not have other related tables in a resulting database;
Is MDA Model Element: is a special Boolean flag on the associated Entity/Node Type for Value Type, and indicates whether the Value Type belongs to a M2 layer metamodel or not, rather than a regular Object-Role Model as projected by the software using the/a model within the metamodel.
Mastering Object-Role Modeling
You can read the concepts explored in this article in my book, “Mastering Object-Role Modeling”, available on Amazon. Excerpt follows:
1.1.1 Reference Modes / Simple Reference Schemes
The Reference Mode of an Entity Type is a way of uniquely identifying an Entity of an Entity Type. As a person, you are most familiar with this concept. You may have a nick name, and in a limited Universe of Discourse (say your family) just your nick name could identify you uniquely. Your nick name, in ORM terms, may be your Reference Mode. Similarly, if you were to join the military forces, you may be allocated a service number in a much larger UoD. That service number would then be a means of referring to you. That first name or service number may be thought of as your Reference Mode. In many database settings an integer based Reference Mode, such as service number, is quite common with the bounds of integers, for example, far exceeding conceivable nick names.
When you define an Entity Type in ORM, you may only define one Reference Mode. In the example below, within the Universe of Discourse each person is referenced by a unique identifier called, ‘PersonId’.
1.1.1.1 Reference Modes and Relational/Graph Schema
From the point of view of a relational and graph database schema, a simple reference scheme represents where a table or node type corresponding to an entity type has a single column/property primary key, and a compound reference scheme equates to where the table has two or more columns/properties in the primary key. See the next sub-section, Compound Reference Schemes for more information.
1.1.1.2 Reference Modes, Shortcuts and Implied Fact Types
Reference Modes may be written in short form. For example, the Reference Mode, (.Id), for a Person Entity Type intimates that each instance of a Person in our UoD is identified by their Person_Id, and where Person_Id is a Value Type in our UoD.
Each Reference Mode may be expanded to see the Fact Type, Internal Uniqueness Constraints and Value Type that form that Reference Mode, as follows:
1.1.2 Compound Reference Schemes
A Compound Reference Scheme, or Composite Reference Scheme is a reference scheme where instances of a model element (Entity Type or Objectified Fact Type) are uniquely identified by instances of two or more associated Value Types.
For instance, an Entity Type, Employee, may have two associations via the Fact Types, Employee has one first-Name and Employee has one last-Name, with associated facts, “Employee, 1, has first-Name, ‘Peter’” and “Employee, 1, has last-Name, ‘Smith’”, identifying the entity, Peter Smith. The associated Value type is Name, but instances of Name are used in two contexts, first name and last name. The corresponding Object-Role Model is shown below:
Note that the Employee, Peter Smith, can also be identified by the Employee_No, 1, but this is not the preferred way of identifying an employee in this universe of discourse. The uniqueness of values for Employee_No in the Fact Type, Employee has Employee_No is guaranteed by the two horizontal purple bars over the roles of the Fact Type, being Internal Uniqueness Constraints. The purple round circles joining the Roles joined to the Entity Type, Employee, are Mandatory Constraints, intimating that each Employee must have a first name, last name and Employee_No. The round circle with the double horizontal bar in the middle is an External Uniqueness Constraint ensuring uniqueness of combinations of first-Name and last-Name in facts of the Fact Type, Person has first-Name and Person has last-Name, and the double bar indicates that it is the Preferred Identifier for Employee. We discuss the role of Preferred Identifiers next.
NB See the chapters on Fact Types and Constraints for more information on Internal Uniqueness Constraints and External Uniqueness Constraints.
1.1.3 Preferred Identifiers
Instances of an Entity Type [1] can have identifiers and preferred identifiers, where a preferred identifier falls under what is known as the Preferred Identification Scheme[2].
A Preferred Identification Scheme is the preferred, or primary, way in which instances of an Entity Type or an Objectifying Entity Type (for an Objectified Fact Type) are identified within a universe of discourse. When an Object-Role Model is viewed as a relational model, for instance, preferred identifiers become primary keys against entities.
Preferred Identification Schemes are signalled within an ORM diagram as double purple bars for an Internal Uniqueness Constraint or External Uniqueness Constraint. An example of both follows below. Figure 3.2 shows an Entity Type with a Reference Mode signalled by the Fact Type, Employee has Employee_No, with a double barred Internal Uniqueness Constraint above the role joining Employee_No, indicating both the Reference Mode and the Preferred Identification Scheme.
Figure 3.3, below, indicates that instances of the Entity Type, Employee, are uniquely identified by their first-Name and last-Name and the External Uniqueness Constraint of the Preferred Identification Scheme has a double bar in its centre, as opposed a single bar for an External Uniqueness Constraint that is not a Preferred Identifier.
[1] Including the Objectifying Entity Types of Objectified Fact Types.
[2] As determined by constraints, Preferred identifiers are also covered in the chapter titled, Constraints.
— -
Thank you for reading. As time permits, I will write more about the Boston Object-Role Modeling metamodel, and the atoms of a Knowledge Index and Knowledge Graph.
==================End=================
