A group of attributes that identify and describe one occurrence of an entity is called an instance of an entity.
For example, if 10,000 employees are stored in a database, then there are 10,000 groups of attributes that represent 10,000 unique instances of the employee entity. An instance of an entity is the equivalent of a record in a table. Because every entity must have an entity identifier (key attribute), each instance of an entity contains a data value that is its unique identifier.
Every instance of an entity is distinguishable from every other instance of an entity because of its unique key attribute value. Unlike entities and attributes, instances of entities do not appear on an ER diagram. To conceptually represent several (possible) instances of an employees entity,
for example, a graphic such as the following is drawn (the red boxes around the random numbers indicate entity identifiers):
A semantic object model (SOM) is intended to represent a system at a fairly high level. Though the ideas are somewhat technical, they still relate fairly closely to the way people think about things,
so semantic object models are relatively understandable to users.
Intuitively a semantic class is a type of class that you might want to represent in your system.
This can include physical objects such as
- people,
- furniture,
- inventory items, and
- invoices.
It can also include logical abstractions such as report generators, tax years, and work queues.
Technically a semantic class is a named collection of attributes that are sufficient to identify a particular entity.
For example, a PERSON class might have FirstName and LastName attributes. If you can identify members of the PERSON class by using
their FirstName and LastName attribute values, then that is good enough.
By convention, the names of semantic classes are written in ALL CAPS as in EMPLOYEE, or WORK_ORDER.
Some prefer to use hyphens instead of underscores so the last one would be WORK-ORDER.
A (SO)
semantic object is an instance of a semantic class. It is an entity instance that has all of the attributes defined by the class filled in. For example, an instance of the PERSON class might have
FirstName 'Bernhard' and LastName 'Riemann'.
Traditionally the attributes that define a
semantic class and that distinguish semantic objects are written in mixed case as in LastName, InvoiceDate, and RoboticBear.
Attributes come in three flavors:
- simple,
- group, and
- object.
A simple attribute holds a simple value such as a string, number, or date. For example, LastName holds a string and EmployeeId holds a number.
A
group attribute holds a composite value, a value that is composed of other values. For example, an Address attribute might contain a Street, Suite, City, State, and ZipCode.
You could think of these as separate attributes but that would ignore the structure built into an address. These values really go together so, to represent them together, you use a group attribute.
An
object attribute represents a relationship with some other semantic object. For example, a relationship may represent logical containment. A COURSE class would have a STUDENT object attribute to represent the
students taking the course. Similarly the STUDENT class would have a COURSE object attribute representing the courses that a student was taking. Each of these classes is related to the other so they are called paired classes.
Similarly their related attributes are called paired attributes. The next lesson describes attribute domains and domain types.