I allowed student\IDs to connect with remote desktop.

1

• I allowed student\IDs to connect with remote
  desktop.  All the users should have a STUDENT
  domain ID. 
• Vrbsky-win7-05                130.160.47.147
• vrbsky-win7-01                 130.160.68.12
• vrbsky-win7-06                 130.160.47.199
• Oracle user name firstname_initial and lastname
• Pw CWID
• Host string XE
• Use SQL plus to type in info interactively
• More info

2

• Object-Oriented Databases
• Chapter 11

3
 

• Limitations to the relational model?
• Examples of applications that will not work well
  with the relational model?

4
Shortcomings of DB models for

• CAD/CAM - keep track of 1000's of matching parts
  and subassemblies
• relational inefficient for this
• object versioning
• complex market-oriented operations (securities)
• geographical information systems
• CASE
• multimedia databases
• WWW

5
Different because of

• requirements and characteristics that differ from
  traditional business applications
• more complex structures for objects
• new data types for storing images, text, user
  defined types
• nonstandard application specific operations

6
OODB systems

• Prototypes ORION, IRIS, ENCORE,
• Commercial products ObjectStore V7.3, Versant
  V8, Objectivity/DB10
• Discontinued Itasca based on Orion, POET
• Open source object database
• PostgreSQL 9.1
• Perst (McObject) supports SQL, ACID, etc.
• Db4o queries only in Java, C, VB.NET (owned by
  Versant)
• Magma 4.2 Squeak (smalltalk-Gemstone)

7
Different approaches to designing OODB

• 1. Applications written in extension of existing
  OOPL (1st generation OODB) to include
• DB functionality
• store and manage objects created by OOPL
• DB features such as transactions, concurrency
  control, etc.  
• Selling point - unified programming and DB
  language but need query optimization, etc. 
• Gemstone (Smalltalk), Poet (C)

8
Designing contd

• 2. Extend relational DB to include OO
  features
• OID, type hierarchy, inheritance, encapsulation,
  arbitrary data types, nested objects, etc.
• Query language extended with programming
  capability
• application communicates with DBMS through
  embedded query language calls in application
  program
• Already familiar with DBMS but performance
  decreased  
• Postgres - extended Ingres, Oracle

9
Designing contd

• 3. Start entire process from scratch (next
  generation?)
• unify relational and OO system  

10
Object Data Model - ODM

• Bring concepts of OOPL into DB systems
• Object corresponds to mini-world object
• Object is data and behavior, object has
  attributes and operations (methods)
• Encapsulation (SQL, optimization?)
• Data object has OID immutable
• Identity vs. value based
• Generated by system
• Group data objects into classes (or types) -
  abstract mechanism, share same structure and
  behavior

11
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 hierarchy (ISA) specialization - define
  new classes from existing ones
• inheritance of attributes and methods - reuse

12
ODM

• Encapsulation
• implementation hidden
• define behavior of object using operations
• object accessible through predefined operations
• If query on attributes?
• SQL violates encapsulation
• SQL for visible (OSQL), rest is encapsulated

13
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

14
ODM

• Add features such as
• concurrency
• recovery
• schema evolution
• Versions
• What about query language?
• Performance?

15
OODB Manifesto

• OODB Manifesto - 1989
• types vs. classes
• Superficially types the same as classes
• types - for variables, statically verify, check
  for correctness, intent
• class
• extension of type, collection of objects
  regardless of type
• not only for correctness, but create and
  manipulate objects at run time
• can create new classes at runtime, etc.
• Hence, gt1 class equivalent in type
• If no dynamic binding, type always determines
  object class

16
OODB Manifesto

• extensibility of types
• predefined types - but user defines new types
  and methods
• no distinction between user and system created
  types
• composite types

17
OODB Manifesto

• other features           OID - distinct,
  immutable           computational completeness
            overriding - inheritance
            overloading           late binding
            concurrency and recovery           ad
  hoc query facility - SQL included
• optional           versioning

18
OODB Manifesto

• complex objects
• apply constructors to new objects
• built arrays or sets of objects
• encapsulation
• can only access object through method
• program data independence
• difficult for query optimization

19
OODB Manifesto

• class or type hierarchies
• subtype (subclass) inherits data and methods,
  and add some of its own
• multiple inheritance

20
ODM

• Object identity OID
• correspondence between real-world and database
  objects
• OIDs like RIDs except can point to other OIDs
• used to refer  to objects in application programs
  and in references between objects(relationships)
• unique over entire DB and even over distributed
  DB

21
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

22
OIDs in reality

• in extended ODMSs, query language extended to
  allow access by OID
• in OOPL, allow value based access by key
• in Postgres - oid attribute in every tuple

23
OID Implementation

• 1.  physical address - fast
• rarely  used, cannot move or delete - if so, all
  references must be changes also
• 2.  structured addresses - popular, 1-2 disk
  accesses
• physical and logical component    segment and
  page and logical slot number         if
  change, use forwarding 

24
OID Implementation contd

•    3.  surrogates - poorer retrieval
• purely logical
• use any algorithm to produce unique IDs (e.g.
  date, time)
• use hash index to map to physical address
  (Postgres)
• object pages are hash buckets - single disk
  access

25
OID Implementation contd

• 4.  typed surrogate - like surrogate for
  retrieval
• contains type ID and object ID
• can obtain type without fetching it - ORION
• difficult to change type - may be useful to be
  able to segment address space (distributed)

26
OID Implementation

• More efficient for artificially generated
  identifiers
• Performance improved if generate OID to speed
  object lookup

27
Swizzling

• All references in cached objects replaced with
  object's address
• pointer to other memory resident objects -
  swizzling
• saves OID lookup with subsequent references

28
Implementation Issues

• pointer (OID) to nested object
• nested - no joins needed
• path queries instead of joins
• when bring in an object into memory, bring in
  nested objects as well
• replace OID with memory address (can't do this in
  relational)
• eager and lazy swizzling
• fast access - memory resident
•  

29
OSQL Object SQL 

• ODMG (disbanded) provided standards for ODB just
  like relational databases.
• Result is OSQL (object SQL)

30
Object-relational - ORDMS

• Informix, IBM, Hewlett-Packard, Unisys, Oracle,
  and UniSQL
• Extended relational" is probably the more
  appropriate term
• ORDMSs specified by the extensions to the SQL
  standard, SQL3/4

31
ORDMS

• Superset of RDMS
• Definition?
• Allows user defined types
• User defined functions
• Indexing/access methods to support them
• ORDBMSs have had their greatest success in
  managing media objects and complex data such as
  geospatial and financial time series data
• frequently used in Web applications and
  specialized data warehouses

32
Oracles object relational

• Oracle ORDB
• Relaxes 1NF
• Has object types, so users can create tables and
  objects
• Allows users to create
• Types as objects
• Object tables
• OIDs
• Inheritance

33
Create type

• Create type must be followed by a / in SQL Plus
  ( optional)
• No objects created, like a struct type
• // Create object type
• Create type name_t as object
• ( lname varchar(10),
• fname varchar(10),
• mi char(1) ) /
• // Create relational table
• Create table teachers
• ( tid int,
• tname name_t,
• room int) /

34
How to insert?

• Can use object_type_name( ) form as an object
  constructor,
• Builds objects from value of attributes
• Insert into teachers values (1234, name_t(Sky,
  Sue, V), 120)
• NOTE data in name_t is never an OID, it is just
  the data or a copy of the data if stored elsewhere

35
Path queries

• Select t.tname.lname from teachers t where room
  120
• // sometimes aliases are required
• // in my examples always use them

36
Create Object table

• Create type person_t as object
• (ssn int,
• Pname name_t,
• age int)
• /
• Create table people of person_t
• To query people
• // You can use the usual SQL
• Select from people where age gt 25
• //Or you can use value ( )
• Select value(p) from people p where age gt 25

37
Inheritance

• CREATE TYPE vehicle AS OBJECT
• (VID VARCHAR2(20),
• COLOR CHAR(10),
• MAKE VARCHAR2(10),
• MODEL VARCHAR2(10) ) NOT FINAL
• /
• CREATE TYPE car UNDER vehicle
• ( DOORS NUMBER,
• SPORT CHAR(1) )
• /

38
Ref Object reference

• //Use REF keyword to point to a row object
• Create type car_reg as object (
• license int,
• drives ref car)
• Create table registrations of car_reg
• //Use dot notation to follow a REF to derefence a
  REF
• Select r.drives.vid from registrations r
• // or can use DEREF to dereference
• Select DEREF(drives) from registrations
• //If you want to display the OIDs of the objects
  in a table use
• Select REF(p) from people p
•          

39
Examples

• Notice the difference between a REF and the
  object_type_name( ) form
• How to insert tuples and query
• Example of object-relational in Oracle
• Results from above in SQL
• Example if creating objects with circular
  dependencies
• Set (collection of objects) nested tables or
  VARRAY

40
Nested tables

• create type dependent_t under person_t(
• essn ref employee_t,
• relationship varchar(10))
• create type dependent_tbl as table of dependent_t
  

41
Nested tables

• Create type employee_t under person_t(
• ssn int,
• address varchar(30),
• dependent dependent_tbl
• You also need
• Create table employee of employee_t nested table
  dependent store as dependent_table

42
Methods

• member function getName return name_t is
• begin
• return name_t(fname, minit, lname)
• end get Dependent

43
Methods

• MEMBER FUNCTION getGender return varchar is
• BEGIN
• IF self.sexM then
• return Male
• ELSE
• return Female
• END IF
• END

44
Methods

• create type employee_t as object (
• ssn int, etc.
• member function getGender return varchar,
• member function getName return name_t)

45
To invoke methods

• Select e.getName(), e.getGender() from employee
  e

46
Performance

• Performance of OODB affected by
• cache sizes
• clustering (all of same class together versus
  subclass follows superclass)
• Nested objects
• Indexes (just like relations)
• views
• swizzling
• Replication
• Versions (replicate common data?)

47
Versions

• Shared version (not updatable)
• Check out and update
• Deleted only by owner
• Working version
• Update/delete by owner
• New transient derived from existing one
• Existing promoted to working

48
Versions

• Version hierarchy - timestamps user specify
  versioned object trace version history delete
  version (delete all versions created from it
  or just most recent) merge
• Class if versionable
• Generic object
• Default version
• Next version
• Version description
• Working or transient

49
OODB issues

• physical OODB design
• clustering problems (NP-hard)
• placing objects onto pages so number of page
  faults is minimal
• user hints for clustering
• where to stores objects, near related objects
• how to store objects, near related objects

50
Example

• e.g.  Bob is a person, but also an employee  
  store all persons   Bob Sally Joe Bill          
  Bob Bill        Sally Joe        person          
               employee       students   if
  store extra attributes, must also retrieve
  information from person class
• store as       employee   student retrieve
  all of them for person

51
Schema evolution

• Schema evolution
• dynamically define and modify DB schema
• invariant - set of properties of the schema
• rules for preserving invariance
• 2 types of schema changes
• 1.  definition of a class (contents
  (attribute/method) of node)
• 2.  to structure (edges and nodes)