ChiMu  
 
Menu Edge About   Products   Services   Projects   Publications  
  Publications > Foundations of O-R Mapping      Previous Page Previous TOC Next Next Page

Relational Modeling

Relational Terminology Common Database Terminology Summary

Relational modeling describes a system’s information as truth statements. We will tell the database truth axioms about the world and the database will remember these truths and even be able to prove other "new" (derived) truths from its model and our axioms. We must also have a way to be sure we understand what we are telling the database and what the database is telling us: we must be able to translate between the human knowledge and the database model. All of this is accomplished in the relational model through well-defined terms like relation, tuple, domain, and database.

Relational Terminology

The following describes the concepts to the relational model. Most of these are identical to the definitions given in [Date 95], but I draw a finer distinction between certain terms (specifically relation and relation value).

Relation

A relation is a truth predicate. It defines what attributes are involved in the predicate and what the meaning of the predicate is. Frequently the meaning of the relation is not represented explicitly, but this is a very significant source for human error in using the database system. An example of a relation is:

Person: {SSN#, Name, City} There exists a person with social security number SSN#, who has the name Name, and lives in a city named City.

Attribute

An attribute identifies a name that participates in the relation and specifies the domain from which values of the attribute must come. In the above relation, Name is an attribute defined over the String domain. The above relation should explicitly identify the domains for each attribute:

Person: {SSN# : SSN, Name : String, City : CityName} There exists a person with social security number SSN#, who has the name Name, and lives in a city named City.

Domain

A domain is simply a data type. It specifies a data abstraction: the possible values for the data and the operations available on the data. For example, a String can have zero or more characters in it, and has operations for comparing strings, concatenating string, and creating strings.

Tuple

A tuple is a truth statement in the context of a relation. A tuple has attribute values which match the required attributes in the relation and that state the condition that is known to be true. An example of a tuple is:

<Person SSN# = "123-45-6789" Name = "Art Larsson" City = "San Francisco">

Tuples are values and two tuples are identical if their relation and attribute values are equal. The ordering of attribute values is immaterial.

Attribute Value

An attribute value is the value for an attribute in a particular tuple. An attribute value must come from the domain that the attribute specifies.

Relation Value

A relation value is composed of a relation (the heading) and a set of tuples (the body). All the tuples must have the same relation as the heading and, because they are in a set, the tuples are unordered and have no duplicates. A relation value could be shown as a set of tuples:

{ <Person SSN# = "123-45-6789" Name = "Art Larsson" City = "San Francisco">,

<Person SSN# = "231-45-6789" Name = "Lino Buchanan" City = "Philadelphia">,

<Person SSN# = "321-45-6789" Name = "Diego Jablonski" City = "Chicago"> }

It is more common and concise to show a relation value as a table.

: Person

SSN#

Name

City

123-45-6789

Art Larrson

San Francisco

231-45-6789

Lino Buchanan

Philadelphia

321-45-6789

Diego Jablonski

Chicago

In this representation, the heading is specified by the ": Person", the attributes of the heading are ordered (for presentation only) by the column headings, and the rows define what tuples exist.

All ordering within the table is artificial and meaningless. The following is a different presentation of the identical relation value.

: Person

City

SSN#

Name

Philadelphia

231-45-6789

Lino Buchanan

San Francisco

123-45-6789

Art Larrson

Chicago

321-45-6789

Diego Jablonski

Relation Variable

A relation variable holds onto a single relation value at any point in time, but can change value at any point in time. Relation variables are typed to a particular relation, so they will always hold relation values that have a heading with that relation. A relation variable would look like:

People : Person

This shows the variable name "People" and the variable relation type "Person".

Using the tabular structure from above, we can show a relation variable and its current value.

People : Person

City

SSN#

Name

Philadelphia

231-45-6789

Lino Buchanan

San Francisco

123-45-6789

Art Larrson

Chicago

321-45-6789

Diego Jablonski

Database

A database is a collection of relation variables. It describes the complete state of an information model, can change state (by changing the relation variables), and can answer questions about its particular state.

Base Relation Values

A base relation value has been explicitly told to the database at some point in time. The above People relation could be such a base relation, in which case we explicitly told the database that Lino Buchanan and Art Larrson are people.

Derived Relation Values

Derived relation values are calculated from other relation values known to the database. For our example data, the number of people located in each city is:

: PersonCount

City

Count

Philadelphia

1

San Francisco

1

Chicago

1

Which can be derived from the information in the "People" relation variable.

Derived relation values are most commonly the result of relational expressions and queries. They are also frequently permanently remembered (and recalculated) through views: derived relation variables.

Coupling between relations, variables, and values

Relations, variables, and values are more coupled than they may first appear to be. Because a relation includes a meaning, a relation variable must have the same meaning as the relation. So defining a variable "HappyPeople : Person" does not make sense because the predicate for ‘Person’ does not describe happiness. What we are really saying is we have a new relation ‘HappyPerson’ which is almost identical to person but has a slightly extended meaning:

HappyPerson: {SSN#, Name, City} There exists a person with social security number SSN#, who has the name Name, and lives in a city named City, and that person is happy.

or using a more concise definition

HappyPerson extends Person: And that person is happy.

New anonymous relations are produced for all derived values (except the identity transformation). This can cause confusions because the anonymous relations are not well defined and different users of the database may have different interpretations.

Common Database Terminology

The previous section defined the correct relational model terminology, but databases have a longer history with different terms that are now overloaded to apply in the relational context. The approximate equivalencies between these terms are given in the following table.

Common

Relational

table

relation variable

row

tuple

column

attribute

column value

attribute value

database

database

Summary

Relational modeling works in terms of predicates, truth axioms, and derivable truth statements. Relations define the possible truth statements, tuples describe the current known truths, relation values collect truth statements together, relation variables remember values, and relation expressions can derive new values.

The relational model is very different from the object model. In many ways the difference is helpful because in most areas object and relational modeling are orthogonal: their concerns are completely different. The next chapter introduces how to integrate the two approaches.

 
Publications > Foundations of O-R Mapping Previous Page Previous TOC Next Next Page