Limitations of the relational model

1. Limitations of the relational model

2. 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?

3. 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.

4. Cont….. • Standards exist both for query languages (SQL) and for interfaces via programming languages (embedded SQL, ODBC) • Why expand to another model?

5. 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

6. 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

7. 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.

8. 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 Works on employee supervision employee project Supervisee ER R

9. 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 Addres Gender Salary Empno Fname initail Sname No street town city PC

10. 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 Every student instructor is both a student and an instructor Classes below inherit attributes from those above Inheritance not in R model person student employee teacher specialisation Student instructor

11. 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

12. Strategies for addressing issues • 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.

13. 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

14. 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.

15. 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)

16. 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

17. 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

18. 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

19. 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

20. 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.