OBJECTS

1. OBJECTS Object Oriented ???????

2. OBJECTS

3. Object-Oriented • OO convenient label for a collection of interconnected ideas • OO approach views computer system as a collection of interacting objects • Objects viewed as things • things interact • people interact with things • Need to know what an object does • Component approach

4. Object-oriented Approach • Object-oriented analysis • defining all of the types of objects that are part of a users work environment • Object-oriented design • define all the types of objects in computer system and how they interact • UML • Object-oriented programming • programmers write statements that define types of objects • C++, JAVA, Small Talk

5. Object-oriented Approach con’t • Object databases - ultimate management system for multimedia, documents and other info. • Object brokers (Agents) - in distributed systems, allow objects to dynamically discover each other and interact across machines and through the web • Object frameworks - provide flexible, customizable, prefabricated software subsystems.

6. OO?? • Object Orientation - a set of design and development principles based on the idea of conceptually autonomous structures. Each autonomous structure represents a real world user's entity with the ability to interact with itself and other objects. • Object - an abstract representation of a real world entity that has a unique identity, embedded properties, and the ability to interact with other objects and itself. • Class - collection of similar objects with shared attributes and methods.

7. Core Model • Class • Object belongs to only one class • is an instance of the class • provides the basis for queries • Class Hierarchy and Inheritance • single inheritance -hierarchy • multiple inheritance- rooted and connected directed acyclic graph (DAG)

8. Core Model • Object Identifier • unique • system-wide • Attributes • value of attribute also object • domain is a class of attribute values • Encapsulation and Message Passing

9. Object-oriented concepts • Abstraction, encapsulation, information hiding. • Objects and attributes. • Object identity. • Methods and messages. • Classes, subclasses, superclasses, and inheritance. • Overloading. • Polymorphism and dynamic binding.

11. relations which are sets of tuples Tuple components primitive types Persistence Backup & Recovery Transactions Concurrency Security & Integrity Administration classes which are sets of objects Object components complex types Inheritance hierarchy Methods Methods integral part of class and inherited DML and host language can be the same Comparison between Rel DBObj DB

12. Weaknesses of RDBMSs • Poor Representation of "Real World" Entities • Normalization leads to relations that do not correspond to entities in "real world". • Semantic Overloading • Relational model has only one construct for representing data and data relationships: the relation. • Relational model is semantically overloaded.

13. Weaknesses of RDBMSs • Poor Support for Integrity and Enterprise Constraints • Homogeneous Data Structure • Relational model assumes both horizontal and vertical homogeneity. • Many RDBMSs now allow Binary Large Objects (BLOBs).

14. Weaknesses of RDBMSs • Limited Operations • RDBMs only have a fixed set of operations which cannot be extended. • Difficulty Handling Recursive Queries • Extremely difficult to produce recursive queries. • Extension proposed to relational algebra to handle this type of query is unary transitive (recursive) closure, operation.

15. Weaknesses of RDBMSs • Limited Operations • RDBMs only have a fixed set of operations which cannot be extended. • Difficulty Handling Recursive Queries • Extremely difficult to produce recursive queries. • Extension proposed to relational algebra to handle this type of query is unary transitive (recursive) closure, operation.

16. Weaknesses of RDBMSs • Other Problems with RDBMSs • Transactions are generally short-lived and concurrency control protocols not suited for long-lived transactions. • Schema changes are difficult. • RDBMSs are poor at navigational access.

17. BENEFITS OF OODBMS • More semantic informatiom • Multimedia, CAD, CAM • User defined data types • Versioning • Class Reusability • Faster development (inheritance, reusability) • Portability

18. DRAWBACKS TO OODBMS • Still developing • Lack of standards • Is there a sufficient theoretical foundation? • Is this a throwback to hierarchical systems • No ad hoc query language • No set of tools • Steep learning curve

19. CURRENT DATABASE FEATURES • Language • DDL • DML • DCL • Concurrency Control • Recovery • Utilities

20. 13 Rules for an OODBMSfrom the OODBS Manifesto • System must support complex objects • Object identifier must be supported • Objects must be encapsulated • Systems must support types or classes • System must support inheritance • System must avoid premature binding • System must be computationally complete

21. LAST 6 RULES • System must be extensible • System must be able to remember data locations • System must be able to handle very large databases • System must support concurrent users • System must be able to recover from hardware and software • Data query must be simple

22. Key Tensions • Two data models needed • object model (data & programs) vs. relational model (data & constraints) • Must one model dominate? Are they built simultaneously? • relational model needs some object features • Impedance mismatch • object-at-a-time navigation vs. set-at-a-time queries • programmatic vs. declarative integrity enforcement • Concurrency discordance • single image vs. shared database mindset • Interoperability • what other applications must use database?

23. Commercial OODBMSs • GemStone from Gemstone Systems Inc., • Itasca from Ibex Knowledge Systems SA, • Objectivity/DB from Objectivity Inc., • ObjectStore from eXcelon Corp., • Ontos from Ontos Inc., • Poet from Poet Software Corp., • Jasmine from Computer Associates/Fujitsu, • Versant from Versant Object Technology.

24. NEXT GENERATION DB SYSTEMS NEED THE ABILITY TO: • represent and manipulate complex nested objects • store and retrieve long data • define and manipulate arbitrary data types • represent and manage changes over time (versions) • represent semantic modeling concepts • specify rules and extended constraints • manage long-duration cooperative transactions

25. Relationships • Relationships represented using reference attributes, typically implemented using OIDs. • Consider how to represent following binary relationships according to their cardinality: • 1:1 • 1:* • *:*.

26. 1:1 Relationship Between Objects A and B Add reference attribute to A and, to maintain referential integrity, reference attribute to B.

27. 1:* Relationship Between Objects A and B • Add reference attribute to B and attribute containing set of references to A.

28. *:* Relationship Between Objects A and B • Add attribute containing set of references to each object. • For relational database design, would decompose *:N into two 1:* relationships linked by intermediate entity. Can also represent this model in an ODBMS.

29. *:* Relationships

30. Alternative Design for *:* Relationships