Loading...
 

Grammar of enterprise modelling

Page actions
Print

Grammar of enterprise modelling

Introduction

The "grammar" presented here is intended as a brief, summarising guide to the CyberEnterprise business model. The individual bullet points should always be seen in the context of the previous sections.

Information models

  • Information models are initially purely linguistic structures made up of words/phrases.
  • Consequently, information models obey the usual grammatical categories of natural languages. (Example: companies, parts, outgoing invoices, date are nouns, add, subtract, calculate are verbs, earliest, lowest, maximum are adverbs or adjectives)
  • Each information unit of an information model must therefore be precisely describable in purely linguistic terms.

Data fields, entities and relations

  • Data fields are the smallest information units of an information model.
  • Data (fields) are formed from simple, complex data types (objects) and relations to data fields (pointer, REL_1M, REL_MN). (Example: text (STRING, MULTIPLE_STRING), real numbers with or without a unit (INTEGER, CX_NUMERIC, CX_FLOAT, CX_VALUE), date (CX_DATE, CX_SPAN_DATE, CX_PERIODIC_DATE))
  • Data (fields) are grouped into semantically related entities (classes) and thus represent the nouns or main words of the information model. (Example: person CX_PERSON, part/article CX_ITEM)
  • The existence or non-existence of data (fields), entities and/or relations in an entity has its own information content per se.
  • The data fields grouped in an entity are described by their name. (Example: CX_PERSON::name, CX_ITEM::description)
  • These data field names can be formed with specifying prefixes (attributive adjectives). (Example: CX_PERSON::middle.name, CX_ITEM::temporary.description)
  • Relationships between entities are generally to be regarded as reciprocal (back references), but cannot be implemented in this way for purely technical reasons.
  • Data fields can be accessed across entities via navigating access paths. (Example: CX_PERSON::father.name, where father is a relation to a CX_PERSON object)
  • The information content of relations themselves can be extended or changed (wrapper concept, description of the edge).
  • Entities can be extended by any entities, data (fields) and/or relations (container principle, slots).
  • Entities can be restricted in their validity depending on their use (validity, security, domains).
  • Entities, their data (fields) and the relations to other entities are defined and manipulated with the help of a data processing system.

Enterprise model

  • An enterprise model defines a (technically) basic but (business-orientated) restricted or expandable network of relationships between entities.
  • The (technical) network of relationships between these (technically) different entities is independent of its utilisation.
  • A use case only defines the scope of use and the "view" of data (fields) and their relationships with each other, but not its (technical) basic structure.
  • Identical (technical) entities can be differentiated in their (business-orientated) use (concept of pseudo-classes).
  • Entities of an enterprise model are (technically) differentiated into information data (basic objects), master data (business objects), transaction data (transactions (OLTP)) and accounts (data cubes (OLAP)).

Master data

  • "Master data" is divided into "real things" (material, tangible) and "concepts" (immaterial, non-tangible).
  • "Terms" stand for themselves or have a relationship to "real things". They fulfil the task of describing the properties/function of real things (role concept). (Example: company (tangible)/customer (intangible), building (tangible)/warehouse (intangible))
  • "Real things" can be related to any number of "concepts" and/or extended by any number of "concepts".
  • "Terms" can (should) only be related to other "terms" if the "terms" are orthogonal to each other. (Example: cost centre / warehouse)
  • "Master data" can be categorised/structured. (Example: companies according to sales areas, articles according to article groups)
  • "Master data" is described in more detail using "information data". (see section Data fields, entities and relations)
  • "Master data" forms the focus for "transaction data".
  • "Master data" can have any number of "accounts" (monitors) defined from different processing aspects, which hold the corresponding "transaction data". (Example: Financial accounting account with journal data, customer sales account with outgoing invoices)

Transaction data

  • "Transaction data" can be posted in and out according to rules (business logic)
  • "Transaction data" changes the status and accounts of related "master data" during each posting process by means of the data (fields) accessible via the "transaction data" (business process I). (Example transaction (rule) description for goods receipt document: Quantity delivered increases the stock of an item warehouse account)
  • "Transaction data" changes its own status with each posting process (business process II). (Example: order status: opened, submitted, ordered, cancelled)
  • "Transaction data" have "transaction data" as predecessors and successors (business process III). (predecessors and successors relations)

Accounts

  • "Accounts" have any number of sub-accounts of any dimensions, which are created automatically using rules.
  • "Accounts" and their sub-accounts are only posted to using rules, i.e. setting and changing data (fields) and registering or deregistering "transaction data".
  • "Accounts" and their sub-accounts support the "drill-down" to "transaction data". "Accounts" and their sub-accounts support the "roll-up" to the "master data" they own.