Thinking at the Conceptual Level

artificer - 2007-06-02 15:03:36 in General
Category: General
Reviewed by: artificer   
Reviewed on: Jun 02 2007

To verify semantics in any business domain, business rules need to be validated with domain experts. The problem is that software developers usually present these rules in the form of a database schema, something almost all domain experts will fail to understand. In the previous article, I discussed briefly the importance of giving semantics to data being stored in a system, but how should we communicate the structure of that data to someone who knows nothing about databases? The answer is to verbalize their business rules at a conceptual level, a language-agnostic approach that most people should have no trouble understanding. This level is very user-friendly because it describes the Universe of Discourse in natural human concepts and strives to union semantics and data to create a concrete understanding of the data and how it is being used. This article focuses on thinking at a conceptual level and verbalizing information at that level.

There are two main components of the conceptual level of information: the conceptual schema and the conceptual database. The conceptual schema houses the structure of the UoD (which includes objects and the roles they play along with particular constraints that include these roles). The conceptual database instead indicates what content fills the structure specified by the conceptual schema. If you're familiar with implementing a database, you'll know that the logical schema looks like a table structure with foreign key relationships between those tables, and the logical database is the actual data that populates those tables. In these respects, the conceptual level and the logical level are homologous, but there is another component in the conceptual level: the conceptual information processor. The CIP controls updates to both the conceptual schema and conceptual database by serving as the mediator between humans (such as a domain expert) and the knowledge base (a combination of the conceptual schema and database). An illustrative example is provided by the diagram to the left.

It is important to remember that the CIP does not specify the conceptual schema, but merely interprets it. The modeler is the one who actually defines the conceptual schema. Of course in some small systems one person may play both of these roles, but it is good practice to distinguish them. Next we'll take a look at what composes the conceptual schema and what work the CIP does.

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:

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.

To understand the context in which base fact types, constraints, and derivation rules take place, consider the following examples of portions of business domains. (The real domains would be much larger.) For each business domain, we will attempt inserts and deletes into the conceptual database to test these constraints. Here is an example.

Sample Domain: Apartment Complex

Base Fact Types:

- Remember, these are templates in which you can plug information, as we will see when we populate them later on.
  1. F1: Person (ID) has FirstName().
  2. F2: Person (ID) has LastName().
  3. F3: Person (ID) lives in Apartment(Nr).
  4. F4: Apartment (Nr) is in ApartmentBuilding (Nr).

Constraints:

- These specify what information is allowed and not allowed in the fact type populations.
  1. C1: Each Person has exactly one FirstName.
  2. C2: Each Person has exactly one LastName.
  3. C3: Each Person lives in at most one Apartment.
  4. C4: Each Apartment is in exactly one ApartmentBuilding.

Population:

  1. add: Person with ID '1' has FirstName 'George'.
    • This would not go in, because it violates constraint C2.
  2. begin:
    • add: Person with ID '1' has FirstName 'George'.
    • add: Person with ID '1' has LastName 'Smith'.
    end
  3. This is accepted. Because this is done in a transaction, we evaluate constraints after both inserts are made.
  4. add: Apartment with Nr 1044 is in ApartmentBuilding with Nr 5.
    • This is accepted. No constraints are violated.
  5. add: Person with ID '1' lives in Apartment with Nr 1044.
    • This is accepted. No constraints are violated.
  6. del: Apartment with Nr 1044 is in ApartmentBuilding with Nr 5.
    • This is denied. Because Apartment 1044 is still in the information system (Person with ID '1' lives in Apartment with Nr 1044.) and every Apartment must be in an ApartmentBuilding, this violates C4.

The rest of these execises are for you to gain some familiarity with thinking at the conceptual level. The answers are at the bottom of the page. I will leave it up to you to decide whether the addition or deletion is allowed; if it is not allowed, try to figure out why it is not allowed.

Domain 1: General Store

Base Fact Types:

  1. F1: Employee (ID) has Name().
  2. F2: Employee (ID) was hired on Date(MDY).
  3. F3: Employee (ID) had employment terminated on Date(MDY).

Constraints:

  1. C1: Each Employee has exactly one Name.
  2. C2: If some Employee had employment terminated on Date then that Employee was hired on some Date.

Population:

  1. add: Employee with ID '1' has Name 'Alex Trebek'.
  2. add: Employee with ID '1' was hired on Date with MDY-CE Value 12-21-2006.
  3. add: Employee with ID '2' was hired on Date with MDY-CE Value 12-22-2006.
  4. del: Employee with ID '1' has Name 'Alex Trebek'.
  5. add: Employee with ID '3' has Name 'Brian Stanley'.
  6. add: Employee with ID '3' had employment terminated on Date with MDY-CE Value 12-27-2006.

Domain 2: Relationships

Base Fact Types:

  1. F1: Person (ID) has Name().
  2. F2: Person is a friend of Person.

Constraints:

  1. C1: Each Person has exactly one Name.
  2. C2: No Person is a friend of himself.
  3. C3: If Person 1 is a friend of Person 2, then Person 2 must not be a friend of Person 1.

Population:

  1. add: Person with ID '1' has Name 'Martin Hartford'.
  2. add: Person with ID '1' is a friend of Person with ID '1'.
  3. add: Person with ID '2' has Name 'Rex Rogers'.
  4. add: Person with ID '1' is a friend of Person with ID '2'.
  5. add: Person with ID '3' is a friend of Person with ID '2'.
  6. add: Person with ID '2' is a friend of Person with ID '1'.
  7. begin:
    • del: Person '1' has Name 'Martin Hartford'.
    • del: Person '1' is a friend of Person '2'.
    end
  8. add: Person '1' is of Gender 'M'.

Domain 3

Base Fact Types:

  1. F1: User(ID) has UserName
  2. F2: User has Password.
  3. F3: User has EmailAddress.

Constraints:

  1. C1: Each User has exactly one UserName.
  2. C2: For each UserName, at most one User has that UserName.
  3. C3: Each User has exactly one Password.
  4. C4: For each EmailAddress, at most one User has that EmailAddress.
  5. C5: Each User must have at most two EmailAddresses.

Population:

  1. add: User with ID '1' has UserName 'Artificer'.
  2. add: User with ID '1' has Password 'phE7aJe5'.
  3. begin:
    • add: User with ID '1' has UserName 'Artificer'.
    • add: User with ID '1' has Password 'phE7aJe5'.
    end
  4. add: User with ID '1' has EmailAddress 'one@devpen.com'.
  5. add: User with ID '2' has UserName 'Artificer'.
  6. begin:
    • add: User with ID '2' has UserName 'Redemption'.
    • add: User with ID '2' has Password 'phE7aJe5'.
    end
  7. add: User with ID '2' has EmailAddress 'two@devpen.com'.
  8. add: User with ID '2' has EmailAddress 'one@devpen.com'.
  9. add: User with ID '2' has EmailAddress 'three@devpen.com'.
  10. add: User with ID '2' has EmailAddress 'four@devpen.com'.

Answers