Semantic Object Model
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
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).
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
Object classes are represented by rectangles
with the object class name in capitals above or below the rectangle.
|Each object has properties which represent how the users view the data.
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.
properties can also include other objects.
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
a property of INVOICE.
object property is represented by a smaller rectangle, containing the capitalised name of
the property, within the main object class rectangle.
|Properties, regardless of whether they are object or
non object properties, can be
single or multi valued.
Teachers may have more than one phone extension, so the non object property Ext, is
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.
|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 groups are represented by a bracket indicating that the
properties repeat as a group.
|Objects can be classified as simple, composite or compound objects.
contains only single valued, non object properties.
OFFERING is a simple object.
object contains one or more non object multivalued properties.
INVOICE is a composite
A compound object contains at
least one object property.
is also a compound object.
|Generalisation is the concept that some objects are
the subtypes of other more general
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
|Revisit the University Database and examine how
the conceptual schema might look using the semantic object model concepts outlined above.
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.
segment contains the methods.