Database Reference
In-Depth Information
Please note:
1.
The natural join is realized by the join logical file in an IBM
System i environment (supported by the operating system),
as well as query and open query. However, generally, the
RDBMS provides the facility to create complex logical views
involving joins of several relations.
2.
On modern systems, the designer is allowed to clearly
define the foreign key constraint at (or subsequent to) the
point of creation of the table
Student
. In more sophisticated
environments (for example, DB2 and Oracle), the foreign key
name could be different from the referenced attribute, so long
as its characteristic features are the same (as mentioned in
previous chapters, it is good design practice to use distinct
attribute names in different relations). In such cases, an
equijoin
(to be clarified shortly) would normally take the place
of a natural join.
3.
The operating system or DBMs traverses both relations and
joins on matching keys i.e. the foreign key in the first relation
is used to reference the primary key in the second relation.
4.
The natural join is associative. Moreover, in specifying it,
it is not necessary to identify the participating attributes,
since they would have been identified when the foreign key
constraint is defined.
Example 4:
To obtain a list showing
Sname
and
Hallname
combinations:
7.3.4 Cartesian Product
Both the Ullman notation and the Date notation essentially agree on the format of the
Cartesian (or cross) product. The
PRODUCT
statement is of the form
The resulting virtual relation has all tuples of the first relation concatenated with all
tuples of the second relation.
