250 likes | 544 Views
Object-oriented DBMS. Background to ODBMS ODBMS requirements Object components ODB conceptual design Graphical ODB schema ODB schema definition (using ODL) Object-relational DBMSs (ORDBMS). Background to ODBMS [1]. Based on concepts and principles of OO programming languages Motivations:
E N D
Object-oriented DBMS • Background to ODBMS • ODBMS requirements • Object components • ODB conceptual design • Graphical ODB schema • ODB schema definition (using ODL) • Object-relational DBMSs (ORDBMS)
Background to ODBMS [1] • Based on concepts and principles of OO programming languages • Motivations: • Direct integration with OO PLs • Easier implementation of multimedia systems • Matches application domain more closely • Encourages modular design • Promotes use of reusable and extensible components
Background to ODBMS [2] • OMG consortium produced ODMG 3.0 standard (1999): • Object model • Object definition language (ODL) • Object query language (OQL) • Bindings to OO programming languages
Background to ODBMS [3] • Advantages: • Ability to deal with complex objects • Improved performance • Disadvantages: • Lack of standards • Lack of security
ODBMS requirements [1] • From OO domain • Support for complex objects (set, tuple, list) • Support for object identity • Support for encapsulation • Support for classes • Support for inheritance (possibly multiple, selective) • Dynamic binding (to allow overloading and overriding) • DML must be “computationally complete” (i.e. a general-purpose PL) • Set of data types must be extensible
ODBMS requirements [2] • From DBMS domain • Data persistence • Ability to manage VLDBs • Support for concurrent users • Ability to recover from hardware / software failure • Facility for querying in a high-level, efficient, application-independent way
Object components [1] • State (value), constructed by type constructor • Atomic type • Structured type: tuple • Collection types: • set (unordered, no duplicates) • list (ordered, duplicates) • References (including inverse references) • Behaviour (operations) • Signature (interface) • Method (body)
Object components [2] • Object identifier (OID) • Logical • Physical
ODB conceptual design • ODB / RDB conceptual design differences • Relationships • ODB - OID references • RDB - value references in foreign keys • Inheritance • ODB - inheritance constructs • RDB - no built-in constructs • Operation specification • ODB - in class specification • RDB - at implementation stage
Graphical ODB schema [1] • Can be mapped from EER schema but • Cannot (directly) model • Categories (union types) • Ternary or higher degree relationships • Relationship attributes • Can model interface inheritance
Graphical ODB schema [2] • Notation (subset only) Class Relationships1:1 1:N M:N Class inheritance Student
Graphical ODB schema: ex [1] Name Address Person Staff# d SeasonTicket Driver Passenger M Reg# M Route# drives travels N N Bus Route 1 runs instance of 1 Capacity From N To N ArrTime Date RouteInstance DepTime
Graphical ODB schema: ex [2] Person Driver Passenger drives travels on is driven by run for Bus Route runs on has instance served by instance of RouteInstance
ODB schema definition • Uses ODL • PL-independent • Specific PL bindings used at implementation • Produced from • EER schema and/or graphical ODB schema • Added class operations
Creating an ODB schema [1] • Stage 1 - create ODL class for each entity type / subclass • Include attributes of EER class • Multi-valued attributes declared with set or list constructors • Composite attributes declared with tuple constructor • Declare an extent for each class • Key attributes are keys of the extent
Creating an ODB schema [2] • Stage 2 - add reference attributes for each binary relationship • Attributes added into participating ODL classes • May be created in one or both directions • One direction - attribute in referencing class • Both directions - inverse • Cardinality ratio • 1:1 / 1:N relationship - reference attributes single-valued • M:N relationship - reference attributes set-valued or list-valued
Creating an ODB schema [3] • Stage 3 - include class operations • Constructor method checks creation constraints • Destructor method checks deletion constraints • Stage 4 - ODL classes formed from EER subclasses • Inherits type and methods of ODL superclass • Define specific attributes, relationship references and operations
Creating an ODB schema [4] • Problem issues • Weak entity types can be defined • In same way as strong entity types • As composite, multi-valued attributes of owner entity type • Categories may be represented by • Declaring class and defining 1:1 relationship with each superclass • Using union type (if available) • Ternary / higher degree relationships may be mapped • Into a separate class with references to participating classes • By 1:N relationship from participating classes to class that represents the higher degree relationship
ODB schema: ex [1] Class Person Attributes: Name (key), Address Class Driver (inherits from Person) Attributes: Staff# (key), set of Bus (reference) Class Passenger (inherits from Person) Attributes: SeasonTicket (key), set of Route (reference)
ODB schema: ex [2] Class Bus Attributes: Reg# (key), Capacity, set of RouteInstance (reference), set of Driver (reference) Operations: getCapacity Class Route Attributes: Route# (key), To, From, set of RouteInstance (reference), set of Passenger (reference)
ODB schema: ex [3] Class RouteInstance Attributes: Date, ArrTime, DepTime, Bus (reference), Route (reference) Operations: getPassengerNumbers, calculateUsage
ORDBMS [1] • Aka extended relational DBMS • Enhance RDBMS with some OO features • Oracle ORDBMS features: • User-defined data types • Object types • Collection types • (Limited) support for multimedia data types • Methods • OIDs • REF data type • (Virtual) object views
ORDBMS [2] • ORDBMS make use of OO features of SQL3 • New data types • Boolean • Character • LOB • Object types and built-in object functions • Inheritance • Collection type constructors • Overloading