Limitations of the Relational Model

Database systems employing object-oriented models have been touted as the emerging form for the next generation of systems. Some say that just as the relational model has supplanted the network (C D!S"#$ and hierarchical models% so too will object-oriented models supplant the relational model.

&uestions' (. !re these predictions true) *. +hat are the reasons behind them) ,o begin% we must examine the strengths and weaknesses of the relational model.

*--.(*((' slides*-' ( of (/

Major strengths of the relational model:

,he data model and access to it is simple to understand and use% even for those who are not experienced programmers.

,he model of data represented in tables is remarkably simple. !ccess to data via the model does not re0uire navigation (roughly% following pointers$% as do the C D!S"# and network models. 1t admits a simple (in principle$% declarative 0uery language.

,here are straightforward database design procedures. ,he data model admits a solid and wellunderstood mathematical foundation (first-order predicate logic$. ,his has facilitated the development of a sophisticated theoretical underpinning% which has contributed greatly to the features of practical systems. 2fficient implementation techni0ues are well known and widely used. Standards exist both for 0uery languages (S&#$ and for interfaces via programming languages (embedded S&# and D3C4C#1$.

*--.(*((' slides*-' * of (/

With all of these strengths, why go beyond the relational model in general, and to an objectoriented model in particular? (. ,here are some forms of data and knowledge which the relational model cannot accommodate easily and ade0uately. *. bject-oriented programming languages are emerging as the dominant form within development environments for large-scale software systems. ! relational database model is not a good match to an object-oriented host language. 5. #anguage-independent system environments which are based upon object-oriented models are emerging% and promise to be extremely important in the future. Dominant example' 67 ( bject 6anagement 7roup$ standards. ,o begin% the first point is examined in more detail.

*--.(*((' slides*-' 5 of (/

Limitations of the Relational Model

1t is convenient to divide the limitations up into two categories. 8irst of all% there are always very special types of data which re0uire special forms of representation and4or inference. Some examples are the following. #imitations regarding special forms of data' ,emporal data Spatial data 6ultimedia data 9nstructured data (warehousing4mining$ Document libraries (digital libraries$ #imitations regarding S&# as the 0uery language' :ecursive 0ueries (e.g., compute the ancestor relation from the parent relation$' !lthough part of the S&#'(;;; standard% recursive 0ueries are still not supported by many systems (e.g. <ostgreS&#$. Support for recursive 0ueries in S&#'(;;; is weak in any case. ( nly so-called linear queries are supported.$ n the other hand% there are also some fundamental shortcomings of the relational model% which are addressed next.

*--.(*((' slides*-' = of (/

Fundamental Limitations of the Relational Model

! "bject identity: 1n entity-relationship modelling% explicit object types% such as Employee, Department, Project, etc.% are specified. 1n the relational model% these may survive only as names of relations.

1n the relational model% entities have no independent identification or existence. bjects can only be identified and accessed indirectly via the identification of those attributes which characteri>e them.

2xample'

1n the Company database of the textbook% it is difficult to speak of an employee as a fundamental entity. !n employee only exists by virtue of a list of attributes in some tables.

*--.(*((' slides*-' . of (/

#! $%plicit relationships: 1n entity-relationship modelling% explicit entities and relationships were specified. 1n the relational model% the identities of relationships have no explicit representation. :elationships must be recovered by executing 0uery operations on the database. ,hese relationships must be known to the user from information not contained in the relational representation. ,here is a hidden semantics in the relational model. 2xample from the Company database of the text'

1n the relational reali>ation of the information embodied diagram shown below% the Supervision relation% as well as the Supervisor and Supervisee r?les% are hidden.
Supervisor 2mployee Supervision Supervisee

*--.(*((' slides*-' @ of (/

1n the following example% the relationship becomes a relation connecting two other relations.

2mployee

+orksB n

<roject

Cours

,hus% the distinction between an entity and a relationship is blurred.

*--.(*((' slides*-' A of (/

&! 'tructured data objects: 8irst normal form ((D8$ stipulates that the values for attributes in a tuple be atomic. ,his prohibits the kind of complex values illustrated below% in which the values of domains are themselves tuples.
Name SSN BDate Fname Minit Address Sex Salary SuperSSN Zip DNO

LName

Street City

State

Dote that this is a natural form of modelling in this application. 1t also prohibits so-called collection types% such as sets% lists% and multisets. ,his is illustrated in the example below% in which a separate relation capturing department locations must be used.
Department
Dname Dnumber MGRSSN MGR-Startdate DLocations

:esearch !dministration Cead0uarters

. = (

555==.... (;;/--.-** ;/A@.=5*( (;;.--(--( ///@@.... (;/(--@-(;

E3ellaire% Sugarland% CoustonF Stafford Couston

*--.(*((' slides*-' / of (/

(! )enerali*ation and inheritance: ,he classes of entities to be modelled in a database often have a natural hierarchical structure. !n example from a university situation is shown below. <erson

2mployee
Speciali>ation

Student ,eacher

7enerali>ation

Student 1nstructor Gey ideas'

,he class of objects associated with a type higher in the hierarchy is a superset of that associated with that of a class lower in the hierarchy 2very 2mployee is a ,eacher. 2very Student 1nstructor is both a Student and an 1nstructor. 8or this reason% these are sometimes called ISA hierarchies.

*--.(*((' slides*-' ; of (/

Classes which lie lower in the hierarchy inherit attributes from those higher up.

!ssume that every person has an SSD. ,hen every Student% 2mployee% ,eacher% and and Student 1nstructor has an SSD also. !ssume that every 2mployee has an employee number. ,hen every ,eacher and every Student 1nstructor has an employee number also% but this is not necessarily the case for <ersons or Students.

+hen an object class inherits attributes from two or more object classes (e.g., Student 1nstructor from both Student and 1nstructor$% it is called multiple inheritance.

1nheritance is not part of the relational model.

*--.(*((' slides*-' (- of (/

+! Methods ften% it is convenient to record explicitly special 0ueries on a database.

1n the relational model% for read-only 0ueries% this may be accomplished via views (although they introduce overhead% due to the need of the system to maintain the current value$. 8or updates% there is no similar mechanism available in the relational model. Such procedures must be maintained outside of the relational model itself.

2xample' !dd a new employee.

*--.(*((' slides*-' (( of (/

Strategies for !ddressing these Shortcomings of the :elational 6odel

,here are two main philosophies' (. 2xtend the relational model to accommodate features which overcome these shortcomings. *. Start over from scratch. 1t is not feasible to extend the relational model in this way. 3oth approaches have been pursued over the past *--*. years.

*--.(*((' slides*-' (* of (/

$%tensions to the Relational Model

! number of vendors have added special features to their relational database systems. Critical constraint'

,he extension must be compatible with the existing S&#'(;;; standard.

Hendors which have followed this line with proprietary commercial products'

racle 136 C< 1nformix 4 1llustra 4 6iro 9niS&#

!lthough some features may be similar% they are not compatible beyond the S&#'(;;; level.

*--.(*((' slides*-' (5 of (/

1n addition% there have been attempts to extend S&# to accommodate desired features.

S&#'(;;; (also called S&#5% S&#-;;$' ! standard which has recently been completed% and which addresses some of these concerns. S&#'*--5 (also called S&#=% S&#'*--n$' ! standard currently under development% which will address other issues.

,hese standards attempt to be compatible with the earlier version of S&# (S&#*% S&#-;*$% with only small changes.

*--.(*((' slides*-' (= of (/

Fundamentally "bject-"riented 'ystems

During the past (. years% a number of objectoriented database systems have been developed. ,hese systems largely abandon the relational model% and start from scratch with an objectoriented one. Some key examples are' * 7emStone bjectStore

2ach system displayed strength for certain types of applications. ,he systems are not compatible with one another.

!fter this initial phase of system development% the various vendors began to develop a standard for the next generation of systems.

,he group is called D67 ( bject Database 6anagement 7roup$.

*--.(*((' slides*-' (. of (/

",erall 'ummary of -urrent .irections

(. /ring database ideas into the e%isting objectoriented world: ,he database model is inherently object orientedI relational ideas are abandoned. ,here is no stand-alone 0uery language. !ccess to the database re0uires a host programming language. 2merging standard' D67 ( bject Data 6anagement 7roup$ proposals. #! /ring object-oriented concepts into the e%isting relational database world: ,he relational model is extended to admit certain object-oriented ideas. !ccess is via an extended version of S&#. !ccess via 0ueries embedded in programming languages is also possible. 2merging standards' S&#'(;;;% S&#'*--n. 1n addition% the following developments are highly relevant. &! .e,elop a general framewor0 for manipulating objects in an interoperable en,ironment! 8ramework is not specific to D36S. 1t deals with general object services in a distributed% heterogeneous environment. 2xisiting standard' 67 ( bject 6anagement 7roup$ proposals.

*--.(*((' slides*-' (@ of (/

'ummary of the $fficacy of 1hese 2pproaches

'3L: 4445'3L:#66n:

,he extensions do add some needed features. Cowever... ,he definitions seem to be ad hoc% and not based upon sound object-oriented theory.

".M) proposal:

,he foundations are much more solid% relative to the foundations of object-oriented systems. Cowever... 6any of the advantages of the relational model are lost.

ne needs a fair amount of expertise to use such systems. Schema design is a much more involved process. 1n many cases% the systems are oriented towards a particular host language.

"M) Framewor0:

,he ideas embodied in this proposal are already becoming a standard. ,he details are outside of the scope of this course.

*--.(*((' slides*-' (A of (/

1he /ottom Line

&uestion' +hich is best)

,he relational model. bject-relational models bject-oriented models

,he inescapable answer'

1t depends upon the application at hand. Do one of these is superior to the others in all possible situations.

! better understanding of these approaches can help one to decide which is most appropriate for a given application% however.

*--.(*((' slides*-' (/ of (/