1 / 21

Limitations of the relational model

Limitations of the relational model. Overview. application areas for which the relational model is inadequate - reasons drawbacks of relational DBMSs. Areas needing advanced database systems. both in terms of structure of data and of operations to be performed on data

maeve
Download Presentation

Limitations of the relational model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Limitations of the relational model

  2. Overview • application areas for which the relational model is inadequate - reasons • drawbacks of relational DBMSs

  3. Areas needing advanced database systems • both in terms of structure of data and of operations to be performed on data • computer aided design (CAD) • computer aided manufacturing (CAM) • computer aided software engineering (CASE) • office information systems, multimedia systems and digital publishing • geographic information systems • etc.

  4. CAD • what is CAD? • do you think CAD needs database systems? • imagine you were going to use a relational DBMS (e.g. Postgres) to support a CAD application; what difficulties do you think you wold encounter?

  5. CAD - characteristics | insufficiency of relational database systems

  6. CAD - characteristics | insufficiency of relational database systems

  7. CAD and relational databases • could you solve any of the problems mentioned, basing your solution solely on features of relational database systems? • the answer is yes, but some of the features you are using in your solutions are (probably) not implicit in the relational model

  8. CAM • similar to CAD but more data processing required • monitoring • control • possibly, both in real time

  9. CASE - characteristics that make it unsuitable for the relational model • (large) data relating to the stages of the software development lifecycle • co-operative engineering • concurrent sharing of project design, code and documentation; • dependencies between components must be tracked • project management • scheduling • cost estimation • progress monitoring

  10. Office Information Systems and Digital Publishing

  11. Geographic information systems • spatial information - not supported by relational DBMSs

  12. Drawbacks of relational databases • poor representation of real world entities • semantic overloading • poor support for integrity constraints • homogeneous data structure • limited operations • difficulty in handling recursive queries • impedance mismatch • other problems ...

  13. Poor representation of real world objects • normalisation -> fragmentation • relations that have no correspondent in the real world • to infer information -> joins -> very costly • poor semantics • everything is a RELATION (see next slide)

  14. Semantic overloading • no distinction between entity and relationship; no distinction between different types of relations (e.g. “has” “is the parent of”, “has the address”, “is located”, “earns”) • result: this semantic cannot be expressed (e.g. be build into the operators) • there is very little meaning in relations (i.e. the systems “knows” very little of the data it contained); what solutions to increase the semantics exist? • domains - provided by the relational model, but not fully supported by relational DBMSs • keys - provided and supported • support for enterprise integrity constraints …?

  15. Poor support for integrity constraints • integrity  validity and consistency • entity integrity + referential integrity + domains • many systems do not fully support -> build them into applications -> effort + inconsistencies • integrity is expressed in terms of constraints (rules that the database must comply with) • the constraint checking mechanism is simple • degree of compliance; categories of integrity constraints ... • what does it mean must comply with? • what is the logical model? must be deduced from the DB? the DB must be consistent with them?must be true of the DB? • the relational model does not support enterprise integrity constraints • SQL provides support for constraints as part of the DB def.

  16. Homogeneous data structure • horizontal and vertical homogeneity • too restrictive • real world objects have a more complex structure • result: unnatural structures + many joins (inefficient) • example: composite parts • on the other hand, this symmetric structure is one of the strengths of the relational model (why?) • binary large objects (BLOB) • are allowed • typically, they are references to files, therefore some advantages provided by DBMSs may be lost (e.g. security) • their inner structure cannot be accessed

  17. Limited set of operations • only a fix set operations • tuple oriented • set oriented • not sufficient for many applications (e.g. geographic information systems - distance, area, …) • no new operations cannot be specified • some DBMSs allow for type extensibility

  18. Difficulty in handling recursive queries Transitive closure

  19. Impedance mismatch • SQL92 lacks computational completeness • solution: embedded SQL • drawback of solution: impedance mismatch • mixing different paradigms • SQL: set based operators • high level programming languages: record based (or even less) (example C) • conversion to records needed (inefficient!) • type mismatch • solution by Date: build set level facilities in high level programming languages

  20. Other problems • other problems also exist • no support for long lived transactions (not inherent to the relational model) • schema amendments - difficult • poor navigational access • therefore, other approaches might be needed

  21. Conclusions • first generation DBMSs • 1060s-1970s • two approaches: hierarchical and network • main problems: complex programs needed to be written to answer simple queries (navigational databases); minimal data independence; no widely accepted theoretical foundations • second generation • 1970 - Codd’s paper • 1970-1980 - many experimental relational DBMSs • now: over 100 commercial DBMSs (some stretch the definition of a relational DBMS) • third generation … (“to be continued”)

More Related