Object-Role modeling is a method of describing the real-world concepts to be modeled in a computer database. In this modeling the objects (people, things, ideas) in the domain under consideration (the problem at hand - customer service, catalog, calendar) play roles (have characteristics, assert restrictions, do things, associate).

To create a model of these objects and their roles we do three things:

1. Write structured descriptions of the facts,
2. Identify objects and construct some rules concerning these objects, and
3. Build ORM schemes that encapsulate the above.

From this model entity-relationship diagrams and database schema are developed, as appropriate.

The last of these three steps, the ORM schemes, are most often portrayed in a graphic-plus-text format. These diagrams are fairly easy to review. Even in that format, to be clearly understood, the models require some familiarity with ORM and the notation. To provide more universal (physical, if not cognitive) access Enosis Group often portrays the model using only text. The improved mobility (e.g., email, ordinary word processors) comes, however, at the price of visual clarity. In either case we recommend that the serious reviewer of the more detailed models become familiar with ORM. (Try, for instance: Conceptual Schema & Relational Database Design, second edition, by Terry Halpin, Prentice Hall, 1995)

Index:
  Reference Schemes
  Stored Fact Types
  Constraints
  Derivation Rules
  Schemes, using Plain Text Notation

Reference Schemes

Declare a reference scheme for entities of interest in problem domain

1. The object name (called "Entity type")
2. How referenced (called "Reference mode")

Notation:
    Entitytype(referencemode)
(Entity type is initial cap, referencemode is in lowercase.)

For example:

Client(name)
Supplier(corpname)
Restaurant(publicname)
Quantity(count+)	Note ORM entities aren't precisely same as ER entities. The "+" indicates that the reference mode is subject to general arithmetic operations for access, indexing, etc. Applicable to, for example: quantities, timestamps.

Note:

1. Each Entitytype plays one or more 'role's in the problem domain.
2. Each referencemode may have a value: 'Chez Louis'.

Stored Fact Types

Declare the properties and roles of facts in problem domain.
By Entityname, referencemode, and role.

1. The entities (Entitytypes)
2. How referenced (referencemode)
3. Role (relationship: -is-a-, -has-a-, and other application-specific items; not exactly OOM.)

For example:

Chef name -cooks- at restaurant	Entitytype=Chef, referencemode=name, Role= -cooks-
Chef name -prepares- cuisine type english	Role= -prepares- (notice that "cuisine type" is ignored)
Fixedmenu day -costs- to prepare $	$ isn't marked with "+" because is not in this case properly the subject of mathematical manipulation as part of Entitytype references
Critic name -publishes- with media

Constraints

Declare rules for ways a population of Entitytype is restricted and validated

1. Static constraint (simple restrictions or validations)
2. Dynamic constraint (constrains transitions in data)

For example:

each Restaurant(publicname) has at least one Owner(ownername)
each Restaurant has at least one Chef	Drop the referencemode when using one declared in Reference Schemes
each Dish(name) is restricted to values [ FISH, FOWL, VEGE, PASTA ]
a Critic eats free only if a Friend
no Restaurant is located in more than one City	(Yes, this has semantic implications.)
each Restaurant is located in exactly one City	Identical to preceeding example
(two-state transition table)
(multi-state diagram)

Derivation Rules

Declare rules for methods to deliver additional Fact Types from these ingredients:

1. These derivation rules
2. Stored Fact Types
3. Constraints

For example:

Chef x works in City y if Chef x works at Restaurant z and Restaurant z is in City y
NumCalories of Menu(menuname) :=: count(Dish(calories) if Dish(dishname) is included in Menu(menuname))

Schemes, using Plain Text Notation

  
Plain-text Construction of ORM Schemes
    
Notation:  
  element ::= element-definition
  {{ any }}  - repeat "any" 0 or more times (without the curly braces)
  (( note )) - explanation, do not use in diagram
  other punctuation in an element-definition is used as shown
   
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

  
scheme ::=   ((structures predicates of entities in roles))   
      schemeidentifier schemepredicate


schemeidentifier ::=
      Sn:  (( Uppercase "S" followed by a sequence number (n) followed by a colon))


schemepredicate ::=   ((structures predicates of entities in roles))   
      schemering
      schemeseq


schemering ::=
      objectspec role

      
schemeseq ::=
      objectspec role objectspec   ((entity(refmode){vals}[rules] -role-))
   |  objectspec role {{ objectspec role }} objectspec
                           ((object plays the immediately following role))


objectspec ::=
      object
   |  object[objectrules]  ((entity(refmode){vals}[rules]))
   |  value

   
object ::=  ((assume any object may have multiple appearances in ORM))
      entityref
   |  entityref{entityalues}
   |  objectified-scheme-name

   
entityref ::=
      entitytype(referencemode)  ((given in Reference declarations, Initial cap))
      entitytype       ((if referencemode is given in Reference declarations))
      entitytypeReferencemode  ((if unambiguous))
   |  super-entity-name

   
objectified-scheme-decl ::=  ((nesting))
      objectified-scheme-name: schemeidentifier  ((of an elsewhere declared scheme))


super-entity-decl ::=
      super-entity-name[super-entity-type]: 
            objectified-scheme-name objectified-scheme-name {{objectified-scheme-name}}
      ((requires that each sub-object be participant in a complete scheme 
             -- identifying objects and roles)) 
      (("EACH sub-object IS-A superentity WHO/THAT/WHICH IS-OF a-scheme"))


super-entity-type ::=
          (( omitted == PARTITION ))
      Z   (( PARTITION: EXHAUSTIVE and EXCLUSIVE ))
      O   (( EXHAUSTIVE: union of subobject populations circumscribe entire superentity
                     i.e., superentity holds no population elements itself )) 
      X   (( EXCLUSIVE: a superentity element may occur in the population of
                     only one of subobjects ))


referencemode ::=
      entitynamekey
      entitynamekey+   ((append "+" if arithmetic ops on key are consistent with meaning))

         
entitynamekey ::=
      key (( how entityname is accessed, as given in Reference declarations.
             Use lowercase when standing alone
             Use Initial cap when unambiguously appended to entitytype ))

  
entityvalues ::=
      valuespec {{ , valuespec }}


valuespec ::=
      valueconstant, valueconstant {{, valueconstant}}  ((a list))
      valueconstant..valueconstant                      ((a sequence))
      unary-logic-op valueconstant                      ((e.g., <6 ))

     
objectrules ::=   ((disambiguate with commas as desired))     
     (( UNIQUENESS CONSTRAINT ))
   |  Un  (( Objects in single scheme (Ss) marked with same Uu form a population. 
             Population in combined objects must be UNIQUE. ))

   |  En  (( Objects in multiple schemes marked with same Ee form a population.
             Population in combined objects must be UNIQUE.
             Recognizes Uu population uniqueness for referenced objects))
   |  En% (( Disjunctive external uniqueness - at most one))

     (( MANDITORY ROLES - recognizes UNIQUENESS rules
      empty == 
         == object is optional, for subtypes and objectified predicates ("nested")
         == "M" -- object is MANDATORY, allowed when object is only one to play role ))
   |  M   (( All of defined population in object MANDATORY in role ))
   |  Mn  (( Each of defined population in object MANDATORY in at least m roles ))

     (( OCCURANCE - population must occur in role number of times specified))
   |  unary-logic-op valueconstant
   |  valueconstant - valueconstant ((a range, inclusive of ends))
   
     (( EXTERNAL RULES ))
   |  Rn  ((The numbered rules, listed elsewhere, apply))


      
value ::=   ((reference specific instance(s) of population of object in foregoing role))
      entitynamekey = valuespec

            
valueconstant ::=
      string
   |  number

      
namestring ::=
      string


role ::= 
      -role-specification-
    ((in this syntax, always read L->R "object -> role -> object -> role -> object" )) 


populationsubset ::=
      commonobject: (Sn)role1 pop-value-subset-rule (Sm)role2 
      ((all objects must share by position similar commonobject)) 

      
pop-value-subset-rule ::=
      subset-of   (( population(RH) is subset of population(LH) ))
   |  equal       (( populations equal ))
   |  exclusive   (( populations mutually exclusive ))
 
   (( Interacts with other rules:
      * The population of one or more combined OBJECT-ROLEs within a single
        scheme may be required to be UNIQUE (occur only once) within that 
        scheme (Un) or across multiple schemes (En) or both.
      * The population of one or more combined OBJECT-ROLEs within a single
        scheme may be required to be a 'SUBSET' of the population of one or
        more combined OBJECT-ROLEs within a different scheme. 'SUBSET' refers
        to the subset operators: subset-of, equal, exclusive. This type of
        requirement (the 'SUBSET' requirement) makes sense only when the
        OBJECT-ROLEs involved share some similarity in their resulting
        population; typically sharing the OBJECT.  
      * An OBJECT may be MANDATORY or optional in a ROLE. If two schemes
        share a single OBJECT (therefore with the same reference mode) with
        MANDITORY status in both roles, then the two OBJECT-ROLE populations 
        will be equal. If, instead, one of the roles is optional, then the
        population associated with the scheme in the optional OBJECT-ROLE
        status will be a subset of the population in the scheme with the
        MANDITORY status.
      * Specifying that one or more ENTITIES are a SUB-ENTITY of another
        ENTITY is a combination of the specifications regarding MANDITORY,
        UNIQUENESS, and 'SUBSET'.
      * 'SUBSET" recognizes UNIQUENESS CONSTRAINT for any object-role 
        instance. ))
   
   (( entityA: (S1)-role1- subset-of (S2)-role2- 
       is implied in following situation:
          S1: entityA[M] role1 entity role value
          S2: entityA[]  role2 entity role value  ))
   
   (( entityA: (S1)-role1- equal (S2)-role2- 
       is implied in following situation:
          S1: entityA[M1] role1 entity role value
          S2: entityA[M2] role2 entity role value  ))
  

external-rules ::=
      Rn: description
      
      ((External rules can be used in place of, or in addition to, and other
        of the notations. One gains visual clarity in the scheme declarations
        but can lose precision. Often used with early stage and higher-level
        models.))
      
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


S1: Expert[M,R1]    -is-on-    Panelname[R1, 4..7]
S1: Expert[R1,1..5] -referees- Papernum(#)[R1, ppr>=2]