2.2. The Conceptual Level

At the conceptual level, all communication between people and the information system is handled by the conceptual information processor. This communication may be divided into three main stages:

In these three stages, the CIP performs as a design filter, data filter, and information supplier, respectively. To process update and query requests, the CIP accesses the conceptual schema, which includes three main sections as shown in Figure 2.4.

A fact (or fact instance) is a proposition that the business takes to be true. The fact types section lists the kinds of facts that may be represented in the database. Fact types indicate what types of object are permitted in the UoD (e.g., Employee, Country), how these are referenced by values in the database (e.g., SSN, CountryCode), and their relationships (e.g., was born in, lives in).

The constraints section lists the constraints or restrictions on populations of the fact types. These may be static or dynamic. Static constraints apply to every state of the database. For example, suppose a database stores information about countries and their populations. Although a country’s population may change over time, at any given time each country has at most one value recorded for its current population. Dynamic constraints determine what transitions are allowed between states of the database. For instance, a person’s age status may change from child to adult, but not vice versa.

Constraints are also known as validation rules or integrity rules. A database is said to have integrity when it is consistent with the UoD being modeled. Although most database constraints can be represented graphically on conceptual schema diagrams, some constraints may need to be represented in other ways (e.g., using conceptual sentences, formulae, tables, graphs, or program code).

The derivation rules section includes rules that may be used to derive new facts from other facts. A fact that is not a derived fact is an asserted fact (also known as a primitive or base fact). Derivation rules may involve mathematical calculation or logical inference. For example, an average score may be derived by summing individual scores and dividing by the number of them. Many operators and functions are defined for various data types. This permits a large variety of possible queries without the need to document each derivation. Typical mathematical facilities include arithmetic operators, such as +, -, * (multiply), and / (divide); set operators such as U (union); and functions for counting, summing, and computing averages, maxima, and minima.

In addition to such generic derivation facilities, specific derived fact types known to be required may be defined in the schema by means of derivation rules. Some mathematically computed fact types and almost all logically inferred fact types fit into this category. Fact types derived by use of logical inference typically involve rules that make use of logical operators such as and or if.

Although derivable facts could be stored in the database, it is usually better to avoid this. Apart from saving storage space, the practice of omitting derived facts from the stored data usually makes it much easier to deal with updates. For instance, suppose we want to regularly obtain individual ages (in years) of students in a class and, on occasion, the average age for the class. If we stored the average age in the database, we would have to arrange for this to be recomputed every time a student was added to or deleted from the class, as well as every time the age of any individual in the class increased.

As an improvement, we might store the number of students as well as their individual ages, and have the average age derived only upon request. But this is still clumsy. Can you think of a better design?

As you probably realized, there is no need to store the number of students in a class since this can be derived using a count function. This avoids having to update the class size every time someone joins or leaves the class. Moreover, there is no need to store even the individual ages of students. Computer systems have a built-in clock that enables the current date to be accessed. If we store the birth date of the students, then we can have the system derive the age of any student upon request by using an appropriate date subtraction algorithm. This way, we don’t have to worry about updating ages of students as they become a year older.

Sometimes, what is required is not the current age but the age on a certain date (e.g., entrance to schooling, age grouping for a future sports competition). In such cases where a single, stable age is required for each person, it may be appropriate to store it.

Before considering a derivation example using logical inference, note the difference between propositions and sentences. Propositions are asserted by declarative sentences and are always true or false (but not both). The same proposition may be asserted by different sentences, for example, “Paris is the capital of France” and “The French capital is Paris”. While humans can deal with underlying meanings in a very sophisticated way, computers are completely literally minded: they deal in sentences rather than their meanings. If we want the computer to make connections that may be obvious to us, we have to explicitly provide it with the background or rules for making such connections.

Suppose that facts about brotherhood and parenthood are stored in the database. For simplicity, assume that the only objects we want to talk about are people identified by their first names. We might now set out facts as follows:

Alan is a brother of Betty.

Charles is a brother of Betty.

Betty is a parent of Fred.

You can look at these facts and readily see that both Alan and Charles are uncles of Fred. In doing so, you’re using your understanding of the term “uncle”. If we want a computer system to be able to make similar deductions, we need to provide it with a rule that expresses this understanding. For example:

Given any X, Y
        X is an uncle of Y if there is some Z such that X is a brother of Z and Z is a parent of Y.

This may be abbreviated to

X is an uncle of Y if X is a brother of Z and Z is a parent of Y.

This rule is an example of a Horn clause. The head of the clause on the left of “if is derivable from the conditions stated on the right-hand side. Horn clauses are used in languages such as Prolog, and enable many derivation rules to be set out briefly. In ORM, such rules are specified using a more readable syntax, e.g.,

For each Person1 and Person2,
       Person1 is an uncle of Person2 if Person1 is a brother of some Person 3
                                                        who is a parent of Person2.

To appreciate how the CIP works, let’s look at an example. The notation is based on a textual ORM language called FORML (Formal ORM Language). A graphical version is explained in later chapters. For simplicity, some constraints are omitted. The UoD structure is set out in the conceptual schema shown.

The reference schemes section declares the kinds of object of interest and how they are referenced. Objects are either entities or values. Entities are real or abstract things that are referenced by relating values (e.g., names) to them in some way. Here we have three kinds of entity: Person, Country, and Year. In this simple UoD, people are identified by their first name (rarely true in practice!). Counties are identified by codes (e.g., ‘ALP for Australia). Years are identified by CE (Common Era) values (e.g., World War II ended in 1945 CE). Years are time segments, so are entities, not values.

The fact types section declares which kinds of facts are of interest. This indicates how object types participate in relationships. In this book, object type names in English are shown with their first letter in capitals, and role names start with a lowercase letter. Since database columns have attribute names like “birthyear”, you may feel it is better to reword “Person was born in Year” as “Person has Birthyear”. However suppose we add another fact type “Person has Deathyear”. The formal connection between Birthyear and Deathyear is now hidden. Expressing the new fact type as “Person died in Year” reveals the semantic connections to “Person was born in Year” and makes comparisons between years of birth and death meaningful (the underlying domain is Year).

Attribute names are often used in ER, UML, and relational schemas to express facts. However, this can be unnatural (compare “Person has deathyear” with “Person died in Year”), and is incomplete unless domain names such as “Year” are added.

The constraints section declares constraints on the fact types. The examples here are all static constraints (i.e., each is true for each state of the database). Reserved words in the schema language are shown in bold. Constraint C1 means that for each person referenced in the database, we know at least one city where they live. C2 says nobody can live in more than one city (at the same time). C3 says nobody was born in more than one year; note that we might not know their year of birth. Constraint C4 says that nobody is his/her own brother, and C5 says that nobody is his/her own parent (brotherhood and parenthood is “irreflexive”).

The derivation rules section declares a logical rule for unclehood and a function for computing the number of children of any person. The unclehood rule is specified in relational style, using fact type readings. The nrChildren rule is specified in attribute style using a role name.

At the conceptual level, each fact in the database is a simple or elementary fact. Basically this means it can’t be split up into two or more simpler facts without loss of information. We may add or insert a fact into the database, and we may delete a fact from it. However we may not modify or change just a part of a fact. By “fact” we mean “fact instance” not “fact type”.

The operation of adding or deleting a single fact is an elementary update or simple transaction. In our sample conceptual query language, add and delete requests start with “add:” and “del:”, and queries start with ”list” or end with “?”. The CIP either accepts updates or rejects them with an indication of the violation. The CIP answers legal queries and rejects illegal ones.

To explain the conceptual notions underlying database transactions, we now discuss some examples of CIP interactions. If this seems tedious, remember that we are talking about the conceptual level, not the external level where the user actually interacts with the system. At the external level, the user typically enters, deletes, or changes values in a screen version of a form or table. Conceptually, however, we may think of such an operation being translated into the appropriate delete and add operations on elementary facts before being passed on to the CIP. Suppose we now start populating our conceptual database as follows:

Because the CIP recognizes the type of this sentence and sees that no constraints are violated, it adds it to the database and issues the reply “Accepted”. If an update is inconsistent with the conceptual schema, the CIP rejects it, indicating the reason for rejection by verbalizing the constraint(s) violated. You should now be able to follow the following dialog. To save space here, we list just the number of the constraint violated rather than its verbalization.

Now suppose that Norma moves from the United States to Australia. How would we record this change? Here are two incorrect attempts:

Is there any way to change Norma’s country of residence? Yes. Sometimes it is convenient, or even necessary, to submit many elementary updates in a single, compound transaction. To show this, we use “begin” and “end” as brackets to open and close the transaction. With compound transactions, the CIP considers only the total or collective effect of the transaction. It is quite possible that the CIP will accept a compound transaction even if, taken individually, some of its component simple updates would be rejected. To change Norma’s location we proceed thus:

begin
     del: Person ‘Norma’ lives in Country ‘US’.
     add: Person ‘Norma’ lives in Country ‘AU’.
end                                                                                  Accepted.

The CIP accepts a transaction if and only if its overall effect is consistent with the conceptual schema. The user entered this compound transaction as a sequence of two elementary updates. It is more natural here to specify the delete before the add operation. However, the CIP treats any compound transaction as a set of updates, disregarding the order of the components, and looks only at the total effect. So even if the add operation had been specified before the delete, this would have been accepted with the same result.

Note that the CIP cannot accept just part of a compound transaction: it is case of “all or nothing”. Here are a few more simple interactions:

Now suppose the UoD is changed by adding the following constraint:

C6 Each Person was born in some Year.

Our current database fails to meet this constraint. Suppose we start over with an empty database and try to add the following fact. How would the CIP respond?

add: Person ‘Bernard’ is a brother of Person ‘John’.

This update request is rejected. It violates two constraints (C1 and C6), as all people listed in the database must have both their country and birth year recorded. Chapter 5 uses the terminology “mandatory roles” to describe such constraints.

In general, the order in which constraints are listed does not matter. However, if an update request violates more than one constraint, this order may determine which constraint is reported as violated if the CIP is configured to report at most one violation. In this case, the CIP would respond thus to the previous request: “Rejected. C1 violated”. If the CIP is configured to report all constraint violations, it would instead respond “Rejected. C1, C6 violated”. As an exercise, convince yourself that with C6 added, the following update requests are processed as shown:

add: Person ‘Ken’ lives in Country ‘GB’.	                    Rejected. C6 violated.
begin
     add: Person ‘Ken’ lives in Country ‘GB’.
     add: Person ‘Ken’ was born in Year 1960.
end	                    Accepted.
add: Person ‘Ken’ was born in Year 1959.	                    Rejected. C3 violated.
begin
     del: Person ‘Ken’ was born in Year 1960.
     add: Person ‘Ken’ was born in Year 1959.
     add: Person ‘Erik’ lives in Country ‘NL’.
     add: Person ‘Erik’ was born in Year 1970.
     add: Person ‘Ken’ is a brother of Person ‘Erik’.
end                                                                               Accepted.

The CIP uses the conceptual schema to supervise updates of the database and to respond to questions. Think of the designer of the conceptual schema as the “law giver” and the schema itself as the “law book” containing the laws or ground rules for the UoD. The CIP is the “law enforcer”, as it ensures that these laws are adhered to whenever the user tries to update the database. Like any friendly police person, the CIP is also there to provide information on request.

Whenever we communicate to a person or an information system, we have in mind a particular universe of discourse. Typically, this concerns some small part of the real universe, such as a particular business. In rare cases, we might choose a fictional UoD (e.g., one populated by comic book characters) or perhaps a fantasy world we have invented for a novel that we are writing. Fictional worlds may or may not be (logically) possible.

You can often rely on your own intuitions as to what is logically possible. For instance, a world in which the Moon is colored green is possible, but a world in which the Moon is simultaneously green all over and red all over is not. A possible world is said to be consistent and an impossible world is inconsistent.

As humans, we carry prodigious amounts of information around in our minds. It is highly likely that somewhere in our personal web of beliefs some logical contradictions are lurking. In most cases it does not matter if our belief web is globally inconsistent. When reasoning about a particular UoD, however, consistency is essential. It easy to show that once you accept a logical inconsistency, it is possible to deduce anything (including rubbish) from it—an extreme case of the GIGO (Garbage In Garbage Out) principle.

There are basically two types of garbage: logical and factual. Inconsistent designs contain logical garbage. For example, we might declare two constraints that contradict one another. A good design method supported by a CASE tool that enforces metarules can help to avoid such problems. Many factual errors can be prevented by the enforcement of constraints on the database. For example, a declared constraint that “Each Person was born in at most one Country” prevents us from assigning a person more than one birth country.

Even if the schema is consistent, and the CIP checks that the database is consistent with this world design, it is still possible to add false data into the knowledge base. For example, if we tell the CIP that Einstein was born in France it might accept this even though in the actual world Einstein was born in Germany. If we want our knowledge base to remain factually correct, it is still our responsibility to ensure that all the sentences we enter into the database express propositions that are true of the actual world.

The following exercise provides practice with the concepts discussed in this section and introduces some further constraint types treated formally later.

Exercise 2.2