530 Relational, Object-Oriented and Object-Relational Data Models Antonio Badia University of Louisville, USA Copyright © 2006, Idea Group Inc., distributing in print or electronic forms without written permission of IGI is prohibited. INTRODUCTION The relational data model is the dominant paradigm in the commercial database market today, and it has been for several years. However, there have been challenges to the model over the years, and they have influenced its evolution and that of database technology. The object- oriented revolution that got started in programming languages arrived to the database area in the form of a brand new data model. The relational model managed not only to survive the newcomer but to continue be- coming a dominant force, transformed into the object- relational model (also called extended relational, or universal) and relegating object-oriented databases to a niche product. Although this market has many nontech- nical aspects, there are certainly important technical differences among the mentioned data models. In this article I describe the basic components of the rela- tional, object-oriented, and object-relational data mod- els. I do not, however, discuss query language, imple- mentation, or system issues. A basic comparison is given and then future trends are discussed. BACKGROUND In order to facilitate the comparison among the models, I will use the same example throughout the article. The example involves a universe of people; some are profes- sors and some are students. Each professor works at a department, and some professors chair departments. Students have professors as advisors. The exact situa- tion is depicted as entity-relationship (ER) diagram (Chen, 1976) in Figure 1. The notation given denotes that Chairs is a one-to-one relationship, Faculty is a one-to- many relationship, and Teaches is a many-to-many rela- tionship. Also, Phones is a multi-valued attribute and Student and Professor are subclasses of Person. The inverted triangle symbol is used to denote a class/ subclass relationship; the reader is warned that different authors use different symbols for this purpose. The relational data model (Date, 2004) is well known; one simply overviews its main concepts here as it serves as the baseline for the comparison. A domain is a nonempty set; intuitively, it provides a pool of values. Every domain is assumed to come with a name (an infinite number of names, technically). Given a schema or list of domain names R = {A1,…, An}, a relation on R is a subset of the Cartesian product A1 x …x An. The elements of the relation are called tuples; each tuple is made up of a list of values a1,…,an, with ai coming from domain Ai. A key K for relation r in schema R is a subset of R (i.e., a set of attributes) such that, for any two tuples in r, they are the same if they have the same value for K. Intuitively, the key represents (stands for) the whole tuple, a fact that is exploited in relational database design. Usually, the domains allowed in most implementa- tions are data types that the computer can easily handle: different numerical types (integers, reals, etc.), charac- ters, and strings. Most database systems also offer a “date” and a “time” domain, to facilitate expression of temporal information as well as large object types, frequently used to deal with multimedia data. However, no complex types are allowed. “Complex” here means, roughly, offering the ability to store more than one value. Because tuples will be used to represent entities, this means that attributes with multiple values (or many relationships among objects) will force an object to be represented over several tuples–perhaps even over sev- eral tables. This characteristic, called the first normal form, will become an issue later on in this article. A relational-database schema is a set of relation schemas plus a set of integrity constraints. An integrity constraint is a condition specified over the database schema that restricts the data that can be stored in the relations. The most important constraints are the key Figure 1. Entity-relationship diagram for the example