Chapter 5

Domains, Relations and Base Relvars

Introduction
The relational model can be regarded as having three principal parts, having to do
with data structure, data integrity, and data manipulation;

S# NAME STATUS CITY

London, Domains
Paris, etc.
Primary Key

S# S# SNAME NAME STATUS STATUS CITY CITY

S1 Smith 20 London

Cardinality
S2 Jones 10 Paris
Relation
S3 Blake 30 Paris
S4 Clark 20 London
S5 Adams 30 Athens Tuple
s
Attribute
Degree
Figure 5.1 Structural terminology

Suppose a relation as a table, then a tuple corresponds to a row of such a table and an
attribute to a column; the number of tuples is called the cardinality and the number of attributes
is called the degree; and a domain is pool of values, from which t he values of specific attribute
of specific relations are taken.
A relation and a table are not really the same thing, although it is common in practice to
pretend that they are.

Formal relational term Informal equivalents

relation table
tuple row of record
cardinality number of rows
attribute column or field
degree number of columns
primary key unique identifier
domain pool of legal values

Figure 5.2 Structural terminology (Summary)

Domains
 A domain is nothing more nor less than a data type(type for short) possibility a simple
system–defined type like INTEGER or CHAR, more generally user-defined like S# or P#
or WEUGHT or QTY in the suppliers and parts database.
 Strong typing
 Every value has a type
 When ever we try to perform an operation, the system checks that the operands are of
the right types for the operation in question.
 For Example, in the case of type INTEGER:
 The system provides operators ‘=’, ‘<’, and so on, for comparing integers;
 It also provides operators ‘+’, ‘*’, and so on, for performing arithmetic on integers;
 It does not provides operators ‘//’(concatenate), SUBSTR(substring), and so on, for
performing string operation on integers are not supported.
 In the case of type S# :
 Probably define operators ‘=’, ‘<’, and so on, for comparing supplier numbers.
 Probably not define operators ‘+’, ‘*’, and so on, which would mean that arithmetic
on supplier numbers would not be supported for this type.
 For example,
P. WEIGHT + SP.QTY ( Illegal )
P.WEIGHT * SP.QTY (Legal, WEIGHT )
P.WEIGHT = SP.QTY (Illegal )
P.CITY = S.CITY (Legal, BOOLEAN )

Values are Typed

Every value has a type. A given type can be either scalar or non-scalar. A non-scalar type
is a type that is explicitly defined to have user –visible components. In particular, relation types
are non-scalar.
The physical representation of a given scalar value-that is, a given value of a given scalar
type can be arbitrarily complex. In particular, it can have components ( but those components
will not be user-visible).
Scalar types are sometimes said to be encapsulated. They are also sometimes said to be
atomic.
Scalar types do have what are called possible representations, and those possible
representations in turn do have user-visible components.

Type Definition
Type < type name > < possible representation > ----;
The type definition for the suppliers and parts database:

TYPE S# POSSREP (CHAR);

TYPE NAME POSSREP (CHAR);
TYPE P# POSSREP (CHAR);
TYPE COLOR POSSREP (CHAR);
TYPE WEIGHT POSSREP (RATIONAL);
 TYPE QTY POSSREP (INTEGER);
Type Conversion
Consider the following type definition once again:
TYPE S# POSSREP (CHAR);
By default, the possible representation here has the inherited name S#, and hence the
corresponding selector operator dose, too. Thus the following is a valid selector invocation:
S# ( ‘S1’)
Therefore, that the S# selector might be regarded, loosely, as a type conversion operator
that converts character string to supplier numbers. Analogously, the P# selector might regarded
as a conversion operator that converts character strings to part numbers: the QTY selector might
be regarded as a conversion operator that converts integers to quantities: and so on.
The following WHERE clause:
… WHERE P# = ‘P2’
The left comparand here is of type P# and the right comparand is of type CHAR: on the
face of it, therefore, the comparison should fail on a type error.
Conceptually, however, what happen is that the system realizes that it can use the P#
“conversion operator” to convert the CHAR comparand to type P# , so it effectively rewrites the
comparison as follows:

… WHERE P# = P#(‘P2’)
The comparison is now legal.
Operands must always be if the appropriate types, not merely coercible to those tyoes. In
particular we will insists that:
 The comparands for “=”, “<”, and “>” must be of the same type:
 The left and right-hand sides of an assignment (“:=”) must be of the same type.

Concluding Remarks
 First and most important, it means the system will known (a) exactly which
expression are legal, and (b) the type of the result for each such legal
expression.
 It also means that the total collection of types for a given database will be a closed
set, that is, the type of result of every legal expressions will be a type that is
known to the system. Observe in particular that is closed set of type must include
the type boolean or truth value, if comparisons are to be legal expressions!
 In particular, the first that the system knows the type of the result of every legal
expression means it knows which assignments are legal, and also which
comparisons.
Definition of a Relation
Attribute(Attribute name, Attribute value)

A B C Heading
Relation 1 x
a
2 c w

y
Cardinalit
3 e v
Body
Tuple 4 b y
5 d w
6 m z

Degree
Figure (5.3) Relational Data Structure

The visual illustrates the components of the relational data structure:

 Relation;
 Attribute;
 Tuple and key;
 Heading and body;
 Degree and cardinality.

Relation
A relation is a set of tuples defined on a number of attributes.
Attribute
Attributes are like the columns of a conventional table. Each attribute has an attribute
name (like the column heading) and attribute values (like column entries).
Tuple
A tuple can be likened to a row in a conventional table. Each tuple is a set of attribute
values, one for each attribute of the relation. Futhermore, each tuple has the same number of
attribute values.
Heading and Body
As illustrated, the table (relation) has two distinct parts, a heading part and a body part.
The heading part of the table is a simple mathematical set, including a list of attribute names,
one attribute name for each column. Each attribute name must be unique within a table.
The body part consists of a number of tuples. The intersection of a tuple with each column of the
table holds an attribute value. Each column in the body part of the table holds attribute values
corresponding to only one type of attribute. The list of values which attributes in one column can
take is referred to as the domain of that attribute.
Degree
The number of attribute columns of a relation is called the degree of the relation.
Cardinality
The number of tuples of a relation is called the cardinality of the relation.

Properties of Relations
Relations possess certain properties and all of them are important. They are as follows.
Within any given relation:
 There are no duplicate tuples;
 Tuples are unordered, top to bottom;
 Attributes are unordered, left to right;
 Each tuples contains exactly one value for each attribute.
There are no duplicate tuples- This property follows from the fact that the body of the relation is
a mathematical set(i.e. a set of tuples), and sets in mathematics by definitions do not include
duplicate elements.
This first properties as an illustration of the point that a relation and a table are not the
same thing, because a table ( in general) might contain duplicate rows, whereas a relation cannot
contain any duplicate tuples. Since tuples are unique, it follows that at least the combination of
all attributes can ( if necessary ) serve as primary key.
Tuples are unordered ( from top to bottom )- This property also follows from the fact that the
body of the relation is a mathematical set. Sets in mathematics are not ordered. Thus, the order of
the tuples in the relations is immaterial. This second property also serves to illustrate the point
that a relation and a table are not the same thing, because the rows of a table obviously do have a
top-to-bottom ordering, whereas the tuples of a relation do not.
Attributes are unordered ( from left to right )- This property follows from the fact that heading of
the relation is also defined as a set (i.e. a set of attribute ). Each attribute is always referenced by
its name and not by its relative positioning within the header.
Each tuples contains exactly one value for each attribute- This property can be stated as:
 At every row- and – column position within the table, there always exists precisely
one value, never a list of values.

Relation Variables
Relation variables- relvars for short- come in two varieties, base relvars and views (also
called real and virtual relvars, respectively).

Base Relvars Definition

Here is the syntax for defining a base relvar:
VAR <relvar name> BASE <relation type>
<candidate key definition list>
[ <foreign key definition list> ] ;
Here by the way of example are the base relvar definitions for the suppliers and parts database:
 VAR S BASE RELATION
{ S# S# ,
SNAME NAME ,
STATUS INTEGER ,
CITY CHAR } ;
PRIMARY KEY { S#} ;

VAR P BASE RELATION

{ P# P# ,
PNAME NAME ,
STATUS INTEGER ,
CITY CHAR } ;
PRIMARY KEY { P#} ;

VAR SP BASE RELATION

{ S# S# ,
P# P# ,
QTY QTY } ;
PRIMARY KEY { S# , P# } ;
PRIMARY KEY { S#} REFERENCES S
PRIMARY KEY { P#} REFERENCES P ;

The syntax for dropping an existing base relvar:

DROP VAR < relvar name> ;
This operation sets the value of the specified base relvar to an empty relation ( i.e., it deletes all
tuples in the relvar, loosely speaking).
The syntax of INSERT, DELETE, and UPDATE

INSERT INTO <relvar name> <relational expression> ;

Example
INSERT INTO S
RELATION { TUPLE { S# S# ( ‘S6’ ) ,
SNAME NAME ( ‘Smith’ ) ,
STATUS 50 ,
CITY ‘Rome’ } } ;

DELETE < relvar name> [ WHERE <Boolean expression> ] ;

Example
DELETE S WHERE CITY = ‘Paris’ ;

UPDATE <relvar name> [ WHERE <Boolean expression> ]

<attribute update commalist> ;
Example
UPDATE S WHERE CITY = ‘Paris’
STATUS := 2 * STATUS ,
CITY := ‘Rome’ ;