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
does, too. Thus the following is a valid selector invocation:

S# ('S1')
The S# selector might be regarded, loosely, as a type
conversion operator that converts character strings to
supplier numbers.
For example:

…..WHERE P# = P1
• The comparison should fail on a type error

However, the system realizes that the P# is a conversion

operator , so it effectively rewrites the comparison as follows:

…..WHERE P# = P# (‘P2”)
• Invoking a conversion operator implicitly in this way is
known as coercion. However, it is well known in practice
that coercion can lead to program bugs.
• In particular, we will insist that:

• The comparands for "=", "<", and ">" must be on the same
type;
• The comparands for "=", "<", and ">" must be on the same
type;
Concluding Remarks

• First and most important, it means the system will know

(a) exactly which expressions are legal, (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 the result
of every legal expression will be a type that is known to the
system.
• In particular, the fact that the system knows the type of the
result of every legal expression means it knows which
assignments are legal, and also which comparisons.
• We have claimed that domains are type data types, system-
or user- defined, of arbitrary internal complexity, whose
valuable are manipulable solely by means of the operators
defines for the type in question ( and whose internal
representation is therefore hidden from the user).
• We have find that the most fundamental object concept, the
object class, is a data type, system- or user-defined, of
arbitrary internal complexity whose values are
manipulable solely by means of the operators defined for
the type in question (and whose internal representation is
therefore hidden from the user).
RELATION VALUES
First of all, then, here is a precise definition of the term
relation:

• Given a collection of n types or domains Ti (i= 1, 2,.........,n),

is not necessarily all distinct, r is a relation on those types if
it consists of two parts, a heading and a body,* where:

• a. The heading is a set of n attributes of the form Ai:Ti,

where the Ai (which must all be distinct) are the attribute
names of r and the Ti are the corresponding type names (i
= 1, 2,...,n);
• b. The body is a set of m tuples t, where t in turn is a set of
components of the form Ai:vi in which vi is the value of
type Ti - the attribute value for attribute Ai of tuple t (i = 1,
2,...,n).

The values m and n are called the cardinality and the degree,
respectively, of relation r. Points arising from the definition:

1. In terms of the tabular representation of a relation, of

course, the heading is the row of column names and
corresponding type names, the body is the set of data rows.
2. Attribute Ai is said to be of type Ti or defined on type Ti.

3. At any given time there will typically be values of any given

type that do not currently appear in the database as a value
for any of the attributes that are of that type.

4. As stated in the definition, the value n- the number of

attributes in the relation- is called the degree

5. The term n-tuple is sometimes used in place of tuple.

6. To say that relation r has heading H is to say, precisely, that

relation r is of type RELATION{H}.
(S#, SNAME, STATUS CITY)

What this row represent is the following set os ordered pairs:

{S# : S# ,
SNAME : NAME ,
STATUS : STATUS,
CITY : CITY }
(S1, SMITH, 20, LONDON)

What this row really represents is the following set of orederd

pairs:

{S# : S# (‘S1’) ,
SNAME : NAME (‘SMITH’),
STATUS : 20 ,
CITY : LONDON }
PROPERTY RELATION
 Relations possess certain properties, all of them immediate
consequences of the definition of relation given in the
previous subsection. The following are the properties within
any given relation:

1.There are no duplicate tuples.

2. Tuples are unordered, top to bottom.
3. Attributes are unordered, left to right.
4. Each tuple contains exactly one value for each attribute.
RELATION- VALUED
ATTRIBUTES
Fig. 5.3 A relation with a relation- valued
attribute
 DEPT# EMP#
D1 E1
D2 E2
.. ..

Instead of

DEPT# EMP#
D1 E1
.. ..