Database Concepts - Data Warehouse Systems: Design and Implementation - page 21

attributes like Name of the entity type Employees in Fig. 2.1 must be split into
atomic values, like FirstName and LastName in the table of the same name
in Fig. 2.4 . Therefore, a relation R is defined by a schema R ( A 1 : D 1 ,A 2 :
D 2 ,...,A n : D n ), where R is the name of the relation, and each attribute
A i is defined over the domain D i .Therelation R is associated with a set of
tuples (or rows if we see the relation as a table) ( t 1 ,t 2 ,...,t n ). This set of
tuples is a subset of the Cartesian product D 1 × D 2 × ···×D n , and it is
sometimes called the instance or extension of R .The degree (or arity )
of a relation is the number of attributes n of its relation schema.
The relational model allows several types of integrity constraints to be
defined declaratively.

￿ An attribute may be defined as being non-null , meaning that null values
(or blanks) are not allowed in that attribute. In Fig. 2.4 , only the attributes
marked with a cardinality (0,1) allow null values.
￿ One or several attributes may be defined as a key , that is, it is not
allowed that two different tuples of the relation have identical values
in such columns. In Fig. 2.4 , keys are underlined. A key composed of
several attributes is called a composite key ;otherwise,itisa simple
key . In Fig. 2.4 , the table Employees has a simple key, EmployeeID ,
while the table EmployeeTerritories has a composite key, composed of
EmployeeID and TerritoryID . In the relational model, each relation must
have a primary key and may have other alternate keys . Further, the
attributes composing the primary key do not accept null values.
￿ Referential integrity specifies a link between two tables (or twice the
same table), where a set of attributes in one table, called the foreign key ,
references the primary key of the other table. This means that the values
in the foreign key must also exist in the primary key. In Fig. 2.4 , referential
integrity constraints are represented by arrows from the referencing table
to the table that is referenced. For example, the attribute EmployeeID
in table Orders references the primary key of the table Employees .This
ensures that every employee appearing in an order also appears in the
table Employees . Note that referential integrity may involve foreign keys
and primary keys composed of several attributes.
￿ Finally, a check constraint defines a predicate that must be valid
when adding or updating a tuple in a relation. For example, a check
constraint can be used to verify that in table Orders the values of attributes
OrderDate and RequiredDate for a given order are such that OrderDate ≤

RequiredDate . Note that many DBMSs restrict check constraints to a single
tuple: references to data stored in other tables or in other tuples of the
same table are not allowed. Therefore, check constraints can be used only
to verify simple constraints.

As can be seen, the above declarative integrity constraints do not suce
to express the many constraints that exist in any application domain. Such