Chapter 3 The Relational Database Model

49

Chapter 3

The Relational Database Model

Discussion Focus

Why is most of this book based on the relational database model? The answer to that question is, quite

simply, that the relational database model has a very successful track record and it is the dominant

database model in the market.

But why has the relational database model (RDM) been so successful? The Object Oriented database

model (OODM) seemed to be poised to dislodge the RDM in the face of increasingly complex data that

included video and audio … yet the OODM fell short in the database arena. However, the OODM’s

basic concepts have become the basis of a wide variety of database systems analysis and design

procedures. In addition, the basic OO approach has been adopted by many application generators and

other development tools.

The OODM’s inability to replace the RDM is due to several factors. First, the large installed base of

RDM-based databases is difficult to overcome. Change is often difficult and expensive, so the prime

requisite for change is an overwhelming advantage of the change agent. The OODM advantages were

simply not accepted as overwhelming and were, therefore, not accepted as cost-effective. Second,

compared to the RDM, the OODM’s design, implementation, and management learning curves are much

steeper than the RDM’s. Third, the RDM preempted the OODM in some important respects by adopting

many of the OODM’s best features, thus becoming the extended relational data model (ERDM).

Because the ERDM retains the basic modeling simplicity of the RDM while being able to handle the

complex data environment that was supposed to be the OODM’s forte, you can have the proverbial cake

and eat it, too.

The OODM-ERDM battle for dominance in the database marketplace seems remarkably similar to the

one waged by the hierarchical and network models against the relational model almost three decades

ago. The OODM and ERDM are similar in the sense that each attempts to address the demand for more

semantic information to be incorporated into the model. However, the OODM and the ERDM differ

substantially both in underlying philosophy and in the nature of the problem to be addressed. Although

the ERDM includes a strong semantic component, it is primarily based on the relational data model’s

concepts. In contrast, the OODM is wholly based on the OO and semantic data model concepts. The

ERDM is primarily geared to business applications, while the OODM tends to focus on very specialized

engineering and scientific applications. In the database arena, the most likely scenario appears to be an

ever-increasing merging of OO and relational data model concepts and procedures.

Although the ERDM label has frequently been used in the database literature to describe the — quite

successful — relational data model’s response to the OODM challenge, C. J. Date objects to the ERDM

label for the following reasons (set forth in “Back to the Relational Future”

www.dbpd.com/vault/9808date.html):

 The useful contribution of the object model is its ability to let users define their own — and often very

complex — data types. However, mathematical structures known as “domains” in the relational model

Chapter 3 The Relational Database Model

50

also provide this ability. Therefore, a relational DBMS that properly supports such domains greatly

diminishes the reason for using the object model. Given proper support for domains, relational data

models are quite capable of handling the complex data encountered in time series, engineering design,

office automation, financial modeling, and so on. Because the relational model can support complex

data types, the notion of an “extended relational data model” or ERDM is “extremely inappropriate

and inaccurate” and “it should be firmly resisted.” (The capability that is supposedly being extended is

already there!)

 Even the label object/relational data model (O/RDM) is not quite accurate, because the relational

data model’s domain is not an object model structure. However, there are already quite a few

O/R products — also known as universal database servers — on the market. Therefore, Date

concedes that we are probably stuck with the O/R label. In fact, Date believes that “an O/R

system is in everyone’s future.” More precisely, Date argues that a true O/R system would be

“nothing more nor less than a true relational system — which is to say, a system that supports the

relational model, with all that such support entails.”

C. J. Date concludes his discussion by observing that “We need do nothing to the relational model to

achieve object functionality. (Nothing, that is, except implement it, something that doesn’t yet seem to

have been tried in the commercial world.)”

Because C. J. Date is generally considered to be one of the world’s leading database thinkers and

innovators, his observations cannot be easily dismissed. In any case, regardless of the label that is used

to tag the relational data model’s growing capabilities, it seems clear that the relational data model is

likely to maintain its database market dominance for some time. We believe, therefore, that our

continued emphasis on the relational data model is appropriate.

Chapter 3 The Relational Database Model

51

Answers to Review Questions

ONLINE CONTENT

Answers to selected Review Questions and Problems for this chapter are contained in the

Student Online Companion for this book. The Student Online Companion also includes SQL

script files (Oracle and SQLServer) for all of the data sets used throughout the book.

1. What is the difference between a database and a table?

A table, a logical structure that represents an entity set, is only one of the components of a database.

The database is a structure that houses one or more tables and metadata. The metadata are data about

data. Metadata include the data (attribute) characteristics and the relationships between the entity

sets.

2. What does it mean to say that a database displays both entity integrity and referential

integrity?

Entity integrity describes a condition in which all tuples within a table are uniquely identified by

their primary key. The unique value requirement prohibits a null primary key value, because nulls

are not unique.

Referential integrity describes a condition in which a foreign key value has a match in the

corresponding table or in which the foreign key value is null. The null foreign key “value” makes it

possible not to have a corresponding value, but the matching requirement on values that are not null

makes it impossible to have an invalid value.

3. Why are entity integrity and referential integrity important in a database?

Entity integrity and referential integrity are important because they are the basis for expressing and

implementing relationships in the entity relationship model. Entity integrity ensures that each row is

uniquely identified by the primary key. Therefore, entity integrity means that a proper search for an

existing tuple (row) will always be successful. (And the failure to find a match on a row search will

always mean that the row for which the search is conducted does not exist in that table.) Referential

integrity means that, if the foreign key contains a value, that value refers to an existing valid tuple

(row) in another relation. Therefore, referential integrity ensures that it will be impossible to assign a

non-existing foreign key value to a table.

Chapter 3 The Relational Database Model

52

4. A database user manual notes that, “The file contains two hundred records, each record

containing nine fields.” Use appropriate relational database terminology to “translate” that

statement.

Using the proper relational terminology, the statement may be translated to “the table — or entity set

— contains two hundred rows — or, if you like, two hundred tuples, or entities. Each of these rows

contains nine attributes.”

5. Use the small database shown in Figure Q3.5 to illustrate the difference between a natural join,

an equijoin, and an outer join.

FIGURE Q3.5 The Ch03_CollegeQue Database Tables

Chapter 3 The Relational Database Model

53

ONLINE CONTENT

All of the databases used in the questions and problems are found on the Student

Companion Web site for this book. The database names used in the folder match the

database names used in the figures. For example, the source of the tables shown in Figure

Q3.5 is the Ch03_CollegeQue database. The Student Online Companion also includes SQL

script files (Oracle and SQLServer) for all of the data sets used throughout the book.

The natural JOIN process begins with the PRODUCT of the two tables:

STU_CODE

PROF_CODE

DEPT_CODE

100278

1

2

128569

2

1

2

512272

4

1

2

531235

2

1

2

531268

1

2

553427

1

2

100278

2

6

128569

2

6

512272

4

2

6

531235

2

6

531268

2

6

553427

1

2

6

100278

3

6

128569

2

3

6

512272

4

3

6

531235

2

3

6

531268

3

6

553427

1

3

6

100278

4

128569

2

4

512272

4

531235

2

4

531268

4

553427

1

4

Next, a SELECT is performed on the PRODUCT generated in the first step to yield only the rows

for which the PROF_CODE values in the STUDENT table are matched in the PROF table. Because

only the STUDENT table’s PROF_CODE values 1, 2, and 4 yield matches in the PROFESSOR

table, the SELECT yields the following output: