Thinking at the Conceptual Level

Category: General
Reviewed by: artificer   
Reviewed on: Jun 02 2007
» Discuss this topic ( Posts)

The role of Conceptual Information Processor is most often played by a machine, because it must perform functions that are best suited to a machine. At a high-level, here are some of its goals:

  1. Accepting the conceptual schema developed by a modeler if and only if it is valid by the rules of the notation (int this case, ORM).
  2. Accepting data into the conceptual database as entered by the user if and only if it is valid by the rules of the conceptual schema.
  3. Supplying data back to the user about the Universe of Discourse as based on the conceptual database.

But enough of the abstract stuff! Here's where the conceptual level really comes into play. When the CIP wants to make sure that user data is valid, it has to look to the conceptual schema, which includes three major categories of objects: base fact types, constraints, and derivation rules.

Base fact types consist of sentences that express facts about the application domain. Such facts are usually simple and include the objects that are allowed in the UoD (e.g. Person, Pet), how they are referenced or uniquely identified (e.g. ID, Name), and their relationships (e.g. lives in, is of). Here are a few examples:

  • Person (ID) was born in Country (Name).
  • Here, Person and Country are objects, ID and Name are reference-modes, and "was born in" is the relationship.

  • Testimonial (Id) was given by Contact (Id) while representing Company (Id).
  • Here, Testimonial, Contact and Company are objects, each ID is its own reference-mode, and "...was given by...while representing..." is the relationship.

  • Person (SSN) smokes.
  • Here, Person is an object, SSN is the reference-mode, and "smokes" is the relationship.

  • Person (ID) has FirstName().
  • Here, Person and FirstName are objects, ID is a reference-mode, and "has" is the relationship. FirstName does not need an identifier, because it identifies itself. Whenever this happens, the object is usually a character string. How do you identify a character string like "Chris"?

Note that for any fact you can talk about any number of objects; when we take a look at modeling later on, you will notice that these fact types can be accurately represented on a diagram.

Constraints comprise the second part of the conceptual schema. There are two types of constraints: static and dynamic. Static constraints apply to every state of the database. For example, even though people can change their names over time (i.e. losing a maiden name after marriage), at any one time, a Person may have only one Name. On the other hand, dynamic constraints apply only to transitions between states in the database. For example, a Person who is single can change his marriage status only to married, not to widowed or divorced.

The final section of the conceptual schema includes derivation rules, which allows the derivation of new facts from existing facts. These can usually arise from two different methods: mathematics and logical inference. For example, if you want to record facts about someone's age, you could store that information, but why? Everytime a year passed you would have to increment the value by one, and even then you would need to record the person's date-of-birth to be able to accurately update the age. Instead, why not record the person's date-of-birth and then derive the age based on today's date? This shows an example of a mathematical operation (subtraction) to derive age.