Jump to content

Higher-Order Entity Relationship Model


General

  • Ontologically Committed

    Generic
  • Categorical

    Yes

Vertical

  • Parent-arity Type Instance

    Unconstrained
  • Transitivity

    Yes
  • Boundedness Type Instance - Downward

    Bounded
  • Boundedness Type Instance - Fixed Finite Levels

    Not Fixed
  • Boundedness Type Instance - Number of Fixed Levels

    Not applicable
  • Stratification Type Instance

    Unstratified
  • Formal Generation - Whole Part - Fusion

    Not yet assessed
  • Formal Generation - Whole Part - Complement

    Not yet assessed
  • Formal Generation - Type Instance - Fusion

    Not yet assessed
  • Formal Generation - Super Sub Type - Fusion

    Not yet assessed
  • Formal Generation - Super Sub Type - Complement

    Not yet assessed
  • Relation Class-ness Type Instance

    Not yet assessed
  • Relation Class-ness Super Sub Type

    Not yet assessed

Horizontal

  • Spacetime

    Separating
  • Locations

    Not yet assessed
  • Properties

    Not yet assessed
  • Immaterial

    Not yet assessed

Universal

  • Merelogy

    No
  • Interpenetration

    Not yet assessed
  • Materialism

    Not yet assessed
  • Possibilia

    Not yet assessed
  • Criteria Of Identity

    Not yet assessed
  • Time

    Not yet assessed
  • Indexicals: Here And Now

    Supported
  • Higher-arity

    Supported

Higher-Order Entity Relationship Model - HERM 

  1. Overview 

Higher-Order Entity Relationship Model - HERM 

Bernhard Thalheim introduces the Higher-Order Entity Relationship Model, called HERM, in 1992. HERM provides an interesting conceptual data model, as it is strictly founded in theory. 

The Higher-Order Entity Relationship Model is an extension of the Entity Relationship Model. 

Schemata in the Higher-Order Entity Relationship Model can be mapped automatically to relational database schemata. Features of HERM include: the nesting of attributes, higher-order types. 

  1. Top-level 

image.png 

(Talheim, 2007) 

  1. Key characteristics 

HERM is an extension of the Entity Relationship Model. 

A key feature of the HERM is the nesting of attributes. 

Another notable feature of HERM is that explicitly handles higher-order types. 

  1. Relevant extracts 

Generic: 

The extended entity-relationship model is mainly used as a language for conceptualisation of the structure of an information systems applications. (HERMinbrief) 

 

The extended entity-relationship model uses a data type system for its attribute types, allows to construct entity types E $ (attr(E), ΣE) through a set of attributes, and inductively builds relationship types R $ (T1, ..., Tn, attr(R), ΣR) of order i (i ≥ 1) through a set of (labelled) entity types and of relationship types of order less than i and a set of attribute types. Additionally, cluster types C $ T1 . ... . Tn of order i can be defined through a disjoint union . of relationship types of order less than i or of entity types. Entity/relationship/cluster classes contain a set of tuples of the entity/relationship/cluster types. The data type system is typically inductively constructed on a base type B system by application of constructors such as the tuple constructor (..), set constructor {..} and the list constructor < .. >. Types may be optional [..]. The types T can be labelled l : T. The types T are typically extended by a set ΣT of constraints which are defined for components of the type. Only those classes are considered for which the constraints of their types are valid. An entity-relationship schema consists of a set of data, entity, relationship and cluster types which types are inductively built on the basis of the base types. 

[…] A disjoint union . of types whose identification type is domain compatible is called a cluster. We restrict the union operation to disjoint unions since we need to preserve identification. Furthermore, we require that the identification types of the components of a cluster are domain-compatible. Cluster types can be considered as a generalisation of their component types. 

[…] First-order relationship types are defined as associations between single entity types or clusters of entity types. They can also be characterized by attributes. The relationship type of order i is defined as an association of relationship types of order less than i or of entity types and can also be characterized by attributes 

[…] 

Relationship types that have only one component type are unary types. These relationship types define subtypes. If we want to explicitly represent subtypes then we also can use binary relationship types named by IsA between the subtype and the supertype. For instance, the type Professor in Figure 1 is a subtype of the type Person 

[…] 

An object (or a “relationship”) on the relationship type R $ (R1, ..., Rn, {B1, ..., Bk}, id(R), ΣR) is an element of the Cartesian product RC1 × ... × RCn × dom(B1) × ... × dom(Bk). 

(Talheim, 2007) 

The problem of information system design can be stated as follows: Design the logical and physical structure of an information system in a given database management system (or for a database paradigm), so that it contains all the information required by the user and required for the efficient behavior of the whole information system for all users. 

[…] 

We distinguish between specialization types and generalization types. Specialization is used whenever objects obtain more specific properties, may play a variety of roles, and use more specific functions. Typically, specialization is specified through IS-A associations. Specific relationship types that are used for description of specialization are the following types: Is-Specific-Kind-Of, Is-Role-Of, Is-Subobject-Of, Is-Subset-Of, Is-Property-Of, Has-Effect-Of, Has-Function-Of, Is-Partial-Synonym-Of, Entails, and Part-Of. Functions are typically inherited downwards, i.e., from the supertype to the subtype. Generalization is used for types of objects that have the same behavior. The behavior and some of the components may be shifted to the generalization if they are common for all types that are generalized. Typical generalizations are Is-Kind-Of, Considered-As, and Acts-In-Role. 

Time and indexical: 

[…] Data may be temporal and depend directly on one or more aspects of time. We distinguish three orthogonal concepts of time: temporal data types such as instants, intervals or periods, kinds of time, and temporal statements such as current (now), sequenced (at each instant of time) and non-sequenced (ignoring time). 

Talheim, B. (2007). The Enhanced Entity-Relationship Model. 

Kirchberg, M/Link, S.: On the Implication Problem for Functional Dependencies in the Higher-Order Entity-Relationship Model, ADC 2003, pp. 115-124 


User Feedback

Recommended Comments

There are no comments to display.


Top
×
×
  • Create New...