THE RELATIONAL DATA STRUCTURE - IBM Mainframe

The smallest unit of data in the relational model is the individual data value. Such values are assumed to be atomic, which means that they have no internal structure as far as the model is concerned. A domain is a set of all possible data values. For example, in the supplier-parts example, the domain of supplier numbers is the set of all valid supplier numbers. Thus domains are pools of values, from which the actual values appearing in the attributes (columns) are drawn. The domain concept is a very important and integral part of the Relational Model, because it has implications for comparisons and hence for operations such as joins, unions, etc., that directly or indirectly involves such comparisons. (Joins and Unions will be discussed in detail later, but simply speaking, both of them are methods of combining data in more than one table.) If two attributes draw their values from the same domain, then comparisons involving those two attributes make sense, because we are comparing like with like.

Domains are conceptual in nature. They may or may not be explicitly stored in a database as actual sets of values. But they should be specified as part of database definition and then each attribute definition should include a reference to the corresponding domain. Now let us take a look at the relations. A relation on domains, say D1,D2 Dn consists of a heading and a body. The heading consists of a fixed set of distinct attributes, say Al,A2 An, such that each attribute 'Ai' corresponds to exactly one of the underlying domains 'Di'. The body consists of a time-varying set of tuples, where each tuple in turn consists of a set of attribute value pairs (Ai:vi), one such pair for each attribute Ai in the heading. For any given attribute-value pair (Ai:vi), 'vi' is a value from the unique domain Di that is associated with the attribute Ai. We will explain this based on the following example:

EMPLOYEE Table

EMPLOYEE Table

Let us see how the employee relation (EMPLOYEETABLE) measures up to this definition. The underlying domains are the domain of employee numbers (say DI), the domain of employee names (say D2), domain of employee age values (D3) and the domain of employee department names (D4). The heading of the EMPLOYEE_TABLE consists of attributes EMP_MO (underlying domain Dl), NAME (domain D2), ACE (domain D3) and DEPARTMENT (domain D4).

Relational Data Structure

Relational Data Structure

The body of EMPLOYEE_TABLE consists of a set of tuples and each tuple consists of a set of 4 attribute-value pairs, one such pair for each of the four attributes in the heading. Even though, they are used interchangeably, a table and a relation are not really the same thing. For example the rows in a table have an ordering, that is from top to bottom, similarly the columns (from left to right). But the tuples and attributes of a relation, which are mathematical sets, do not have any ordering.

The number of attributes in a relation is called the degree of the relation. A relation of degree one is unary, a relation of degree two is called binary, etc. So the employee relation has a degree of 4.

The number of tuples or rows in a relation Ts called the cardinality of the relation. So the cardinality of the relation EMPLOYEE_TABLE is 5. The cardinality of a relation changes with time as more and more tuples get added or deleted, but the degree does not.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM Mainframe Topics