1. Onject-oriented Database Prof. Sin-Min Lee Department of Computer Science

2. History of data models:

3. 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. 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). Limited Operations – RDBMs only have a fixed set of operations which cannot be extended.

4. Weaknesses of RDBMSs 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. Impedance Mismatch – Most DMLs lack computational completeness. – To overcome this, SQL can be embedded in a high-level 3GL. – This produces an impedance mismatch - mixing different programming paradigms. 30% of programming effort and code space is expended on this type of conversion. 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.

5. Object-Oriented Concepts Object-oriented concepts To start with, a brief review of underlying themes… Abstraction: Process of identifying essential aspects of an entity and ignoring unimportant properties. - Concentrate on what an object is and what it does, before deciding how to implement it. Encapsulation: Object contains both data structure and set of operations used to manipulate it. Information Hiding: Separate external aspects of an object from its internal details, which are hidden from outside. – Allows internal details of object to be changed without affecting apps that use it, provided external details remain same. – Provides data independence.

6. Object-Oriented Concepts Objects and Attributes Object: Uniquely identifiable entity that contains both the attributes that describe the state of a real-world object and the actions associated with it. – Definition very similar to ‘entity’, however, object encapsulates both state and behavior; – an entity only models state. Attribute: Contain current state of an object. Attributes can be classified as simple or complex. Simple attribute can be a primitive type such as integer, string, etc., which takes on literal values. Complex attribute can contain collections and/or references. Reference attribute represents relationship. complex object: contains one or more complex atts

7. Object-Oriented Concepts Object Identity Object identifier (OID) assigned to object when it is created that is: – System-generated. – Unique to that object. – Invariant. – Independent of the values of its attributes (that is, its state). – Invisible to the user (ideally). Advantages: They are efficient. They are fast. They cannot be modified by the user. They are independent of content. - RDBMS: object identity is value-based, primary key provides uniqueness. - Primary keys do not provide type of object identity required in OO systems: –key only unique within a relation, not across entire system –key chosen from atts of relation, making it dependent on object state.

8. Object-Oriented Concepts Methods and messages Method: Defines behavior of an object, as a set of encapsulated functions. Message: Request from one object to another asking second object to execute one of its methods. (a) (b) (a) Object showing atts and methods (b) Example of a method

9. Object-Oriented Concepts Classes Class: Blueprint for defining a set of similar objects. -Objects in a class are called instances. -Class is also an object with own class attributes and class methods.

10. Object-Oriented Concepts Subclasses, Superclasses and inheritance Inheritance allows one class of objects to be defined as a special case of a more general class. Special cases are subclasses and more general cases are superclasses. Generalization: process of forming a superclass Specialization: forming a subclass Subclass inherits all properties of its superclass and can define its own unique properties. Subclass can redefine inherited methods. All instances of subclass are instances of superclass. Principle of substitutability: instance of subclass can be used whenever method/construct expects instance of superclass. A KIND OF (AKO): Name for relationship between subclass and superclass 4 Types of inheritance: 1. single 2. multiple 3. repeated 4. selective

11. Types of inheritance (a) (b) (c) (a) Single (b) Multiple (c) Repeated (b)

12. Overriding and overloading Overriding: Process of redefining a property within a subclass. Overloading: Allows name of a method to be reused with a class or across classes. Overriding Example: Might define method in Staff class to increment salary based on commission method void giveCommission(float branchProfit) { salary = salary + 0.02 * branchProfit; } May wish to perform different calculation for commission in Manager subclass: method void giveCommission(float branchProfit) { salary = salary + 0.05 * branchProfit; }

13. Polymorphism and dynamic binding Polymorphism: Means ‘many forms’. Three types: 1. operation 2. Inclusion 3. parametric. Dynamic Binding: Runtime process of selecting appropriate method based on an object’s type. Example: With list consisting of an arbitrary no. of objects from the Staff hierarchy, we can write:list[i]. print and runtime system will determine which print() method to invoke depending on the object’s (sub)type.

14. Complex Objects Complex Objects: An object that consists of subobjects but is viewed as a single object. Contained object can be encapsulated within complex object, accessed by complex object’s methods. Or have its own independent existence, and only an OID is stored in complex object. Objects participate in a A-PART-OF (APO) relationship.

15. Storing objects in relational databases Storing Objects in Relational Databases One approach to achieving persistence with an OOPL is to use an RDBMS as the underlying storage engine. Requires mapping class instances (i.e. objects) to one or more tuples distributed over one or more relations. To handle class hierarchy, have two basics tasks to perform: (1)design relations to represent class hierarchy; (2)design how objects will be accessed.

16. Storing objects in relational databases Storing Objects in Relational Databases Sample inheritance hierachy for staff

17. Storing objects in relational databases Mapping classes to relations No. of strategies for mapping classes to relations, although each results in a loss of semantic information. 1.Map each class or subclass to a relation: Staff (staffNo, fName, lName, position, sex, DOB, salary) Manager (staffNo, bonus, mgrStartDate) SalesPersonnel (staffNo, salesArea, carAllowance) 2.Map each subclass to a relation Manager (staffNo, fName, lName, position, sex, DOB, salary, bonus, mgrStartDate) SalesPersonnel (staffNo, fName, lName, position, sex, DOB, salary, salesArea, carAllowance) 3. Map the hierarchy to a single relation Staff (staffNo, fName, lName, position, sex, DOB, salary, bonus, mgrStartDate, salesArea, carAllowance, typingSpeed, typeFlag)

18. Next Generation Database Systems First Generation DBMS: Network and Hierarchical –Required complex programs for even simple queries. –Minimal data independence. –No widely accepted theoretical foundation. Second Generation DBMS: Relational DBMS –Helped overcome these problems. Third Generation DBMS: OODBMS and ORDBMS.

19. Object-oriented databases Object-oriented database = a database constructed by applying the object-oriented paradigm – Each data entity stored as a persistent object – Relationships indicated by links between objects – DBMS maintains inter-object links

20. The associations between objects in an object-oriented database

21. OODB Some people felt the word object-oriented is too close to OOPL ODB is more generic

22. Different approaches to designing ODB 1. Applications written in extension of existing OOPL (1st generation OODB) language, compiler, execution environment, etc. extended to incorporate – DB functionality – store and manage objects created by OOPL Selling point - unified programming and DB language but need query optimization, etc. – Gemstone (Smalltalk), Poet (C++)

23. Designing cont’d 2. Extend relational DB to include OO features: OID, type hierarchy, inheritance, encapsulation, arbitrary data types, nested objects, etc. Already familiar with DBMS but performance decreased Postgres - extended Ingres, Oracle

24. Designing cont’d 3. Start entire process from scratch (next generation?) unify relational and OO system

25. Object Data Model Bring concepts of OOPL into DB systems – Object corresponds to real-world object – Object is data and behavior, object has attributes and operations – Data object has OID - immutable – Group data objects into classes - abstract mechanism, share same structure and behavior

26. ODM Class has: – instances – methods and data - encapsulation for information hiding - access only through methods – composite classes - composed of multiple types – nested objects - contains another object – complex objects - set of objects – class hierarachy (ISA) – specialization - define new classes from existing ones – inheritance of attributes and methods - reuse

27. ODM Completeness DBS needs to be computationally complete (Turing) SQL not computationally complete - unless embedded SQL - impedance mismatch, since sets connections with DML and OOPL in ODB more acceptable

28. ODM Add features such as: – concurrency – recovery – schema evolution – Versions – What about query language? – Performance?

29. ODM Object identity OID correspondence between real-world and database objects used to refer to objects in application programs and in references between objects (relationships) unique identity to each independent object

30. OID vs. primary key identity based vs. value-based unique over entire DB and even over distributed DB (if primary key changes, still same real-world object) immutable - values of OID for object should not change - OID not assigned to another object - not dependent on any attribute values - not use physical address system generated OID not visible to user

31. Advantages of object-oriented databases Matches design paradigm of object-oriented applications Intelligence can be built into attribute handlers – Example: names of people Can handle exotic data types – Example: multimedia Can store intelligent entities

32. Desires of the software industry More functionality Less code Reduced internal complexity Standard interfaces Reduced duplication of effort

33. Hope with Objects Objects have been shown to satisfy all five of these desires…

34. Objects satisfy desires… Development effort is reduced – 2 to 1 reductions are common – 5 to 1 frequent – 20 to 1 possible with relevant libraries Continued…

35. Objects satisfy desires Projects tend to meet specs 3 to 1 reduction in control flow complexity Messages allow clean interfaces Objects promote reusability (6 to 1)

36. Traditional Development Real World Design Implementation model developed by designers gets lost in implementation

37. Developing with Objects Real WorldDesign Implementation Design and implementation model directly reflect real world Design remains visible in source code

38. Code Reuse Statistics ProjectTotal Code New Code % ReuseSavings HPMS3,926K1,960K50%$117,000 OSA1,950K327K83%$119,000 SPC1,815K130K92%$248,000 Profit1,940K412K78%$80,000

39. Benefits: Reuse

40. Benefits: Bulk Reduction

41. Benefits: Quality Improvement

42. Objects in a Nutshell… 1. Objects encapsulate data within the set of procedures which can access that data. 2. Programming is done by requesting an object to perform some desired behavior.

43. Objects in a Nutshell… 3. Objects determine at run-time the particular procedure to execute in response to a request. 4. Objects are grouped into classes which describe the common structure and behavior of that class of objects.

44. Objects in a Nutshell 5. Classes are organized hierarchically in order to factor out generic capabilities; thus, eliminating redundancy. 6. Programmers no longer write programs; they develop models of their application or system environment using classes.

45. Objects Encapsulate Data message procedures procedures Objects encapsulate their local data within procedures which have access to that data data

46. Instances Every object is an instance of a generic class of objects An instance describes a single concept or models a real world entity

47. Classes of Objects A class contains – Class’ data template – Class’ available procedures

48. Relating an Object to its Class inherits from ObjectClass name Unique Data Values Data Templates + Procedures

49. Dynamic Binding Objects determine at run-time which procedure to execute The cost is more modest than expected; thus viability of Smalltalk. Time critical applications can combine dynamic and static binding as required (in hybrid languages).

50. Objects Share Classes inherits from Object Class name Unique Data Values Data Templates + Procedures

51. Classes Inherit Classes A class has state information and performs predefined functions A subclass may add or alter the function or state defined in its superclass(es). Integer Number Object

52. Lineage of Object Languages Modula Eiffel Pascal Ada C++ C Objective-C Smalltalk/V AlgolSimulaSmalltalk Actor LispLoops CLOS

53. Inheritance Often shown using a hierarchy diagram Implies that integer is a subset of Number which is a subclass of the Object class Data and procedures are inherited from superclasses Object Number Integer Real

54. The Power of Inheritance Powerful capabilities can be developed near the root of the inheritance tree The root of the tree is the Object class which includes methods such as: size:size in bytes of any object storeOn:to store on disk copy: to make a copy of any object in memory

55. Features / Benefits… EncapsulationBehavior without the burden; reduces side effects Message passingIncapsulates user from the implementation InheritanceCode bulk reduction; modification by specialization continued…

56. Features / Benefits Dynamic binding Replaceable components; enables iterative development Classes Packaging systems into domain meaningful components Modeling language Readability of code; code reflects real world being modeled

57. Pure Object Environments Smalltalk-80 from ParcPlace Systems Smalltalk/V from Digitalk Actor from Whitewater Group

58. Objective-C A small language which allows details of C to be hidden Default is dynamic; static binding also available Interpreter and libraries are available

59. C++ A large but direct extension to C Default is static binding; dynamic also available Minimizes time and space

60. Failures with OOP Designs with too fine grained use of objects Performance – a design failure Bleeding edge – select tools carefully Memory cannot be ignored

61. Futures Visual programming techniques will become commonplace Objects may provide the long awaited key to effective distributed processing – enormous computing power now sits idle on desktops Object oriented databases will become commercial products in the 2000’s

62. Conclusions Objects will change the way software is built, sold and used Objects will take as long as semiconductors to become pervasive