{"id":20462,"date":"2026-01-30T07:35:30","date_gmt":"2026-01-30T07:35:30","guid":{"rendered":"https:\/\/www.booksofall.com\/in\/?post_type=product&p=20462"},"modified":"2026-01-30T07:35:30","modified_gmt":"2026-01-30T07:35:30","slug":"the-theory-of-relational-databases","status":"publish","type":"product","link":"https:\/\/www.booksofall.com\/in\/the-theory-of-relational-databases\/","title":{"rendered":"The Theory of Relational Databases"},"content":{"rendered":"

Chapter 1 – Relations And Relation Schemes<\/a><\/h2>\n

One of the major advantages of the relational model<\/a> is its uniformity. All data is viewed as being stored in tables, with each row in the table having the same format. Each row in the table summarizes some object or relationship in the real world. Whether the corresponding entities in the real world actually possess the uniformity the relational model ascribes to them is a question that the user of the model must answer. It is a question of the suitability of the model for the application at hand.<\/p>\n

Whether or not the relational model is appropriate for a particular set of data shall not concern us. There are plenty of instances where the model is appropriate, and we always assume we are dealing with such instances.<\/p>\n

1.1 Brass Tacks<\/h3>\n

So much for philosophy<\/a>. Let us consider an example. An airline schedule<\/a> certainly exhibits regularity. Every flight listed has certain characteristics. It is a flight from an origin to a destination. It is scheduled to depart at a specific time and arrive at a later time. It has a flight number. Part of an airline schedule might appear as in Table 1.1.<\/p>\n

What do we observe about this schedule? Each flight is summarized as a set of values, one in each column. There are restrictions on what information may appear in a given column. The FROM column contains names of air- ports served by the airline, the ARRIVES column contains times of day. The order of the columns is immaterial as far as information content is con- cerned. The DEPARTS and ARRIVES columns could be interchanged with no change in meaning. Finally, since each flight has a unique number, no flight is represented by more than one row.<\/p>\n

The schedule in Table 1.1 is an example of a relation of type FLIGHTS. The format of the relation is determined by the set of column labels {NUMBER, FROM, TO, DEPARTS, ARRIVES}. These column names are called attribute names. Corresponding to each attribute name is a set of permissible values for the associated column. This set is called the domain of the attribute name. The domain of NUMBER could be the set of all one-, two- or three-digit decimal integers. Each row in the relation is a set of values, one from the domain of each attribute name. The rows of this relation are called S-tuples, or tuples in general. The tuples of a relation form a set, hence there are no duplicate rows. Finally, there is a subset of the attribute names with the property that tuples can be distinguished by looking only at values cor- responding to attribute names in the subset. Such a subset is called a key for the relation. For the relation in Table 1.1, {NUMBER) is a key.<\/p>\n","protected":false},"excerpt":{"rendered":"