Upload
marlene-jones
View
223
Download
2
Tags:
Embed Size (px)
Citation preview
Onject-oriented Database
Prof. Sin-Min Lee
Department of Computer Science
History of data models:
Weaknesses of RDBMSs
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.
Weaknesses of RDBMSs
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.
Object-Oriented Concepts
Object-oriented conceptsTo 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.
Object-Oriented Concepts
Objects and AttributesObject: 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
Object-Oriented Concepts
Object IdentityObject 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.
Object-Oriented Concepts
Methods and messagesMethod: 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
Object-Oriented Concepts
ClassesClass: 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.
Object-Oriented Concepts
Subclasses, Superclasses and inheritanceInheritance 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 ofinheritance: 1. single2. multiple3. repeated 4. selective
Types of inheritance
(a)
(b)
(c)
(a) Single(b) Multiple(c) Repeated
(b)
Overriding and overloadingOverriding: 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; }
Polymorphism and dynamic bindingPolymorphism: 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.
Complex ObjectsComplex 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.
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 moretuples 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.
Storing objects in relational databases
Storing Objects in Relational Databases
Sample inheritancehierachy for staff
Storing objects in relational databases
Mapping classes to relationsNo. 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 relationManager (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 relationStaff (staffNo, fName, lName, position, sex, DOB, salary, bonus, mgrStartDate, salesArea, carAllowance, typingSpeed, typeFlag)
Next Generation Database SystemsFirst 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.
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
The associations between objects in an object-oriented database
OODB
Some people felt the word object-oriented is too close to OOPL
ODB is more generic
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++)
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
Designing cont’d
3. Start entire process from scratch (next generation?)
unify relational and OO system
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
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
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
ODM
Add features such as: – concurrency – recovery – schema evolution– Versions– What about query language?– Performance?
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
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
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
Desires of the software industry
More functionalityLess codeReduced internal complexityStandard interfacesReduced duplication of effort
Hope with Objects
Objects have been shown to satisfy all five of these desires…
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…
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)
Traditional Development
Real World Design Implementation
model developed by designers gets lost in implementation
Developing with Objects
Real World DesignImplementation
Design and implementation model directly reflect real world
Design remains visible in source code
Code Reuse Statistics
Project Total Code
New Code
% Reuse Savings
HPMS 3,926K 1,960K 50% $117,000
OSA 1,950K 327K 83% $119,000
SPC 1,815K 130K 92% $248,000
Profit 1,940K 412K 78% $80,000
Benefits: Reuse
Benefits: Bulk Reduction
Benefits: Quality Improvement
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.
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.
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.
Objects Encapsulate Data
message procedures procedures
Objects encapsulate their local data within procedures which have access to that data
data data
Instances
Every object is an instance of a generic class of objects
An instance describes a single concept or models a real world entity
Classes of Objects
A class contains – Class’ data template– Class’ available procedures
Relating an Object to its Class
inherits
from
Object Class
name
Unique Data
Values
DataTemplates
+Procedures
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).
Objects Share Classes
inherits
from
Object Class
name
UniqueData
Values
Data Templates
+Procedures
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
Lineage of Object Languages
Modula Eiffel
Pascal
Ada C++
C Objective-C
Smalltalk/V
Algol Simula Smalltalk
Actor
Lisp Loops CLOS
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
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 objectstoreOn: to store on diskcopy: to make a copy of any
object in memory
Features / Benefits…
Encapsulation Behavior without the burden; reduces side effects
Message passing Incapsulates user from the implementation
Inheritance Code bulk reduction; modification by specialization
continued…
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
Pure Object Environments
Smalltalk-80 from ParcPlace Systems
Smalltalk/V from DigitalkActor from Whitewater Group
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
C++
A large but direct extension to CDefault is static binding; dynamic
also availableMinimizes time and space
Failures with OOP
Designs with too fine grained use of objects
Performance – a design failureBleeding edge – select tools
carefullyMemory cannot be ignored
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
Conclusions
Objects will change the way software is built, sold and used
Objects will take as long as semiconductors to become pervasive