Transcript Limitations of the relational model

Limitations of the relational
model
Limitations of the relational
model
Just as the relational model supplanted the
network and hierarchical model so too will
the object – orientated model supplant the
relation model ?

Is this true?
 Why?
Major strengths of the
relational model






Data model and access is simple to understand and
use
Access to data via the model does not require
navigation (following pointers) as the network
models
Allows (in principle) declarative query language
There are straightforward DB design procedures
Admits a solid and well understood mathematical
foundation (RA)
Implementation techniques are well known,
efficient and widely used.
Cont…..

Standards exist both for query languages
(SQL) and for interfaces via programming
languages (embedded SQL, ODBC)

Why expand to another model?
Why go beyond the R model

Some forms of data and knowledge which cannot
be accommodated easily and adequately
 OO programming languages are emerging as the
dominant form within development environments
for large-scale software systems.
 Language independent system environments
which are based upon OO models are emerging
and may be extremely important in the future
– Object management group (OMG) standards
Limitation 1

Some forms of data and knowledge which cannot
be accommodated easily and adequately
 There are always very special types of data which
require special forms of representation
– Temporal data, Spatial data, Multimedia data,
unstructured data (WH, DM),Documents libraries
(digital libraries)

Limitations regarding SQL3 as the query language
– Recursive queries
Object identify

ER modelling, object types such as employee,
department, project etc are specified in the R
model these survive only as names of
relations/tables
 In R model entities have no independent
identification of existence, objects are identified
and access via identification of attributes
characterising them
– E.g.: a company db will have an entity of employee, yet
in the R model the employee exists by virtue of a list of
attributes in some tables.
Explicit relationships

ER modelling explicit entities and
relationships were specified in the R model
the identities of relations have no explicit
relations
 Relationships must be known to the user
 There are hidden semantics in the R model
Supervisor
employee
supervision
employee
Supervisee
ER
Works on
project
R
Structured data objects

1NF stipulates that the values for attributes
in a row be atomic
 Prevents complex values below in which
the values of the domains are themselves
rows
– No collection types
Name NI
DoB
Fname initail Sname
Addres
Gender Salary Empno
No street town city PC
Generalisation and inheritance

Classes of entities to be modelling a db
often have natural hierarchical structure
generalisation
Class of objects associated with a type
higher is a superset of that association
Every employee is a teacher
person
student
Every student instructor is both a
student and an instructor
Classes below inherit attributes from
those above
specialisation
Inheritance not in R model
employee
teacher
Student
instructor
methods

Often it is convenient to record explicitly special
queries on a database
 R model for read only queries this is accomplished
via views
– Cost overhead and need system to maintain the current
value

R model of updates has no similar mechanism
procedures must be maintained outside of the
model itself.
– E.g. add employee
Strategies for addressing
issues

1.
2.
2 main philosophies
Extend the R model to accommodate
features to overcome these short comings
Start for scratch
–

It is not feasible to extend the R model in this
way
Both approaches have been tried over the
past 20 years.
Extensions to the R model

A number of vendors have added special features
to their R database
– Constraint! Any extension must be compatible with the
SQL2(SQL-92) standard Oracle, IBM, HP,
Informix/Ilustra/Mico, UniSQL

Although futures may be similar they are not
compatible beyone the SQL2 level
 In addition there have been attempts to extend
SQL to accommodate desired features
Cont…

SQL1999 (AKA SQL3) a standard which
has recently been completed and addresses
some of the concerns
 SQL4 a standard currently under
development to address other issues
 These standards attempt to be compatible
with earlier versions of SQL with small
changes.
Fundamentally OO systems

During the past 20 years a number of OO db
systems have been developed, these largely
abandon the R model and start from scratch with
an OO db key examples are:
– O2, GemStone, OjectStore

Each system displayed strengths for certain types
of application
 System are not compatible with each other
– Lead to need for standards for next generation of
systems ODMG (object database management group)
Overall summary of current
directions

Bring databases ideas into the existing OO
world
– The database model is inherently OO; relational
ideas are abandoned
– There is no stand-alone query language
– Access to the DB requires a host of OO
programming language
– Emerging standard: ODMG proposals
Cont …

Bring OO concepts into the existing
relational database world
– The R model is extended to admit certain OO
ideas
– Access is via an extended version of SQL
– Access via queries embedded in programming
languages is also possible
– Emerging standards SQL3, SQL4
Cont …

Develop a general framework for
manipulating objects in a interoperable
environment
– Framework is not specific to DBMS
– Deals with general object services in a
distributed heterogeneous environment
– Existing standards OMG (object management
group) proposals
Bottom line – which is best?


Relational model v Object relational model V OO model
Depends on the application at hand
 No one of these is superior to the others in
all possible situations
 A better understanding of these approaches
can help to decide which is most
appropriate for a given application
Summary of the efficiency of
these approaches

SQL3/SQL4
– Extensions do add some needed features but definitions
seem to be ad hoc and not based upon sound OO theory

ODMG proposal
– Foundations more solid to OO systems but advantages
of R model lost




Needs expertise to use systems
Schema design is much more involved
In many cases the system are orientated to wards a specific OO
host language.
OMG framework
– Already becoming standard details of which are outside
the scope of the module.