Semantic Object Model

Some Definitions top of page

The Semantic Object Model (SDM) was first described by M. Hammer and D. McLeod in 1981.  Like the ERM, the SDM is used to model the data as a conceptual schema for the database.  The SDM uses semantic objects to represent data and these equate to the entity occurrances of an ERM.  The word semantic means meaning, so the purpose of using semantic objects to represent "things" within an organisation, is to represent more accurately, the users meaning or users perspective of the data.  Throughout this section, semantic objects will be referred to as just objects.

The purpose of an object diagram is to graphically represent the structure of objects: that is to show the properties of objects as well as relationships between objects (which objects contain other objects).

Objects top of page

An object is a "thing" within the organisation, that we want to keep information about.  Objects are grouped into object classes and given capitalised names such as TEACHER or SUBJECT.   An object, sometimes referred to as an object instance, also has a name, such as SUBJECT ICAITS031B.  The name of an object instance can be one property, as in the previous example, or it can be more than one property, such as TEACHER Nelson Jack.

Object classes are represented by rectangles with the object class name in capitals above or below the rectangle.


Properties
top of page

Each object has properties which represent how the users view the data. 

For example:
In an ERM, an INVOICE and INVOICE LINE are represented as two separate entities, each with their own attributes.  A common attribute of both entities is then used to associate them to each other.  INVOICE LINE is considered to be a weak entity in an ERM.

However, from a users point of view, the two are not distinct "things".   When a user thinks of an invoice, they see the invoice lines as being part of, or properties of, an invoice.  Because an SDM models data from the users perspective, the invoice lines are included as properties of INVOICE.  Hence, there are no weak objects in an SDM.

Properties are listed inside the object class rectangle with an initial capital letter.

Invoice properties


Object Properties
top of page

An objects properties can also include other objects.

For example:
In an ERM, a CUSTOMER is also modelled as a separate entity, again with a common attribute to associate it with an INVOICE.

A CUSTOMER is also a separate object in an SDM, because the user sees a customer as being a distinct "thing".  However, a user also sees customer details as being part of, or properties of, an INVOICE.   Therefore, in an SDM, a CUSTOMER object is modelled as a property of INVOICE

Customer object property

An object property is represented by a smaller rectangle, containing the capitalised name of the property, within the main object class rectangle.


Single/Multivalued Properties
top of page

Properties, regardless of whether they are object or non object properties, can be single or multi valued. 

For example:
Teachers may have more than one phone extension, so the non object property Ext, is multivalued.

Teachers can also teach many Subjects, so the object property SUBJECT, is also multivalued.

Multivalued properties are represented by the letters mv next to them.

multivalued properties


Composite Groups
top of page

When properties repeat as a group, but are not considered to be distinct "things", such as the invoice lines example above, they are called composite groups

composite group

Composite groups are represented by a bracket indicating that the properties repeat as a group.


Simple/Composite/Compound Objects
top of page

Objects can be classified as simple, composite or compound objects.

A simple object contains only single valued, non object properties.

For Example:
OFFERING is a simple object.

A composite object contains one or more non object multivalued properties.

For Example:
INVOICE is a composite object.

A compound object contains at least one object property.

For Example:
INVOICE is also a compound object.


Generalisation
top of page

Generalisation is the concept that some objects are the subtypes of other more general objects. 

For example:
FACULTY, ADMIN and MAINT/OPS are subtypes of EMPLOYEE, but are also objects in their own right.  Subtypes are modelled as properties of the general object with an OR between them.  Each subtype is also modelled as a separate object, with the general object as a property.  This illustrates that each subtype inherits the properties of the general object.

Object subtypes

Revisit the University Database and examine how the conceptual schema might look using the semantic object model concepts outlined above.

Object Orientated Programming top of page

The semantic object model we have just discussed is used for database conceptual data modelling.  Don't confuse this model with other object modeling methodologies which are used primarily in the field of software design and object orientated programming.

Because software is often written to access a database, software design quite often involves database design as well.  Hence, object modelling methodologies such as UML (Universal Modelling Language) appear similar to the semantic object model.

However, one major difference between an SMD and the UML methodology is that the UML contains the methods or operations that objects use to process themselves.  When an object inherits another objects properties, it also inherits its methods, therefore programming duplication is reduced.  

The diagram to the right is an example of how the OFFERING object may look in a UML conceptual schema.

The bottom segment contains the methods.

UML object

Semantic Object Modelling Activity
Examine the reports and business rules for the Homewares database. 
  1. Draw the Object diagrams for Homewares.
  2. Include the concepts outlined above where necessary.

top of page