Download Object Oriented Database Systems, Standards, and Languages | ECS 165B and more Study notes Deductive Database Systems in PDF only on Docsity!
1. Object-Oriented Database Systems,
Standards, and Languages
Reading: Chapter 8 (4th ed), Chapter 9 (5th ed)
Topics:
- Database Applications for OODBMS
- Overview of Object-Oriented concepts
- Overview of the Object-Model of ODMG
- Basics of Object-Oriented DB design
Conventional Database Systems and Applications
Features of “traditional” database applications:
- Uniformity: Large numbers of similarly structured data items, all of which having essentially the same size (in bytes).
- Record Orientation: Basic data items consist of (fixed-length) records.
- Small Data Items: Each record (tuple) is short – a tuple rarely requires more than a few hundred bytes.
- Atomic Fields: Fields within a tuple are short, length typically within a specific range, first normal form holds.
Such applications are very well supported by data-processing oriented data models (relational model) and concepts (storage & file structures, query processing & optimization, transaction management etc.)
Emerging “New” Database Applications
Non-standard applications:
- On the Web: online product catalogs, ebay, amazon.com, e-business, e-government,...
- Office Information Systems and Document Management Systems
- Computer-Aided Design Environments (CAD, CAM, CAQ)
- Multimedia Applications (incl. images, video, audio)
- Geographic Information Systems (GIS), Information Management in the Lifesciences, Environmental Information Systems,...
Common properties and problems for these types of applications:
- Need for complex data types and type systems (not just strings and numbers)
- Support of abstract data types (ADTs) and data encapsulation
- Novel methods for querying (navigational/operational support instead of just declarative support) and access structures.
- Sophisticated operations on data structures necessary, much closer on programming concepts in OO programming languages.
- Object-identity is a stronger notion of identity than in programming languages or data models not based on object- orientation (; concept does not apply to tuples of a relational database)
- Some OO models require that everything from simple value to complex object has an OID.
- Object identifiers are used to uniquely identify objects
- stored as a field of an object
- Used to refer to another object, e.g., the spouse field of a person object may be the identifier of another person object
- can be system generated (built-in; created by the DBS) or external (user-supplied)
Object Structure
In OODBS, the state (current value) of a complex object may be constructed from other objects (or other values) using type constructors.
- Basic type constructors are atom, tuple, and set; can also include list, bag, and array.
- Formal representation of an object as a triple (i, c, v), with i being OID, c a type constructor, and v is the object state.
- Examples: o 0 = (i 0 , atom, 815 ) o 1 = (i 1 , atom,′UC Davis′) o 2 = (i 2 , atom,′Computer Science′) o 3 = (i 3 , atom,′Art′) o 4 = (i 4 , set, {i 1 , i 2 }) o 5 = (i 5 , tuple, 〈University : i 1 , Major : i 2 〉)
- Model allows arbitrary nesting of constructors (e.g., bag of lists of sets of numbers)
- Object can be represented as graph with each object oi being a node labeled with OID ii and type constructor ci. If object value is constructed, graph includes arc from object node to node representing constructed value. For each atomic value, graph includes direct arc from object node to node representing the value.
- Graph representation allows to compare states of two objects for equality: - identical states (deep equality): graphs must be identical, including OIDs at every level - equal states (shallow equality): graph structure must be the same, but some nodes may have different OIDs Example of shallow equality: o 1 = (i 1 , tuple, 〈a 1 : i 4 , a 2 : i 6 〉) o 2 = (i 2 , tuple, 〈a 1 : i 5 , a 2 : i 6 〉)
Specifying Object Behavior via Class Operations
Encapsulation and information hiding are core characteristics of OO programming languages. In contrast, in the relational model, all structures are visible and modifications are generic.
- Behavior of a type (class) of object is based on operations that can be applied to objects of that type
- Internal structure of object is hidden and object is only accessible through defined operations; these include object constructor and destructor, object modifiers, and retrieval operations.
- Part of operation visible to the user is called interface (or signature); implementation of an operation is called method.
- Method is invoked by sending a message (including parameters) to object to execute corresponding method; method returns value; methods are typically written in general- purpose programming language.
- Only the implementor can see physical implementation of object, i.e., how a method is realized. Formally, all access operations to an object need to be encapsulated (i.e., set and access methods for each attribute is required). Practically, complete encapsulation is too stringent ; divide structure of object into hidden and visible attributes.
- Example of class definition extending type definition define class Department type tuple (fname: string; ... ); operations (no_of_emps: integer; create_dept: Department; destroy_dept: boolean; assign_emp(e: Employee): boolean);
Object Persistence via Naming and Reachability
- In OO programming languages, objects are transient (i.e., they are destroyed after program termination); persistent objects are stored in DB and persist after program termination. In practice, it is reasonable to have both transient and persistent objects in application programs
- Mechanisms for making an object persistent:
- Naming: persistent object is specified via specific statement or operation in program; persistent objects are used as entry points into the DB. However, it is not practical to explicitly give persistent names to all objects in DB. Thus, a more practical mechanism is
- Reachability: object is persistent by reachability if a sequence of references in the object graph leads to a persistent (named) object.
- Subtype inherits all attributes and operations of predefined type.
- Example: PERSON: name, address, birthdate, age, ssn Subclasses EMPLOYEE subtype-of PERSON: salary, hiredate, job STUDENT subtype-of PERSON: major, gpa
- Substitutability – any method of a superclass can be invoked equally with any object belonging to any of its subclasses
- Multiple Inheritance
- The class/subclass relationship is represented by a directed acyclic graph (DAG) – in such a graph, a class can have more than one superclass.
- A class inherits attributes and methods from all its superclasses.
- Potential for ambiguity, e.g., attributes with the same name. Different solutions, such as flag and error, rename attribute, or choose one.
- One can use multiple inheritance to model roles of an object.
Object Database Standard – ODMG 3.
- Object Database Management Group (ODMG, www.odmg.org) is a subgroup of the Object Management Group (OMG, www.omg.org), formed 1991
- ODMG’s goal is to provide portability for
- Data schemas
- Programming Language Bindings
- Data Manipulation Languages
- Query Languages
i.e., application portability and resolving the impedance mismatch
ODMG Standard Components
- Object Model: types, objects, modeling state/behavior, metadata, concurrency control, transaction model
- Object Definition/Specification Language (ODL)
- Object Query Language (OQL): object identifiers, methods, path expressions, polymorphism
- C++, Smalltalk, and Java language bindings
Example:
interface Employee ( extent EmployeeExtension, keys EmployeeId, (name, DOB) ) { attribute Long EmployeeId; attribute Struct Name { String FirstName, String LastName } name; attribute Struct Address {
... } address; attribute List phones; attribute Date DOB; attribute Short Salary; relationship List participates in inverse Project::members; void raise Salary (in Short amount); };
Object Query Language (OQL)
- Syntactic and semantic extension of the SQL-92 standard. Extensions concern object-oriented notions, like complex objects, object identity, path expressions, operation invocation etc.
- OQL provides high level constructs to deal with sets of objects but is not restricted to this collection construct. It also provides primitives to deal with structures, list, arrays etc.
- OQL is a functional language where operators can freely be composed, as long as the operands respect the type system.
- OQL does not provide explicit update operators but rather invokes operations defined on objects for that purpose.
Examples:
- Complex result type can be constructed in query: select distinct struct(e.name, projects:( select p.projectId from e.participates in prj as p) ) from employee as e Result type: set<struct<name:String, projects:set>>
- Query can include path expressions: select m.name from ( select p.manager from project as p where p.status = ’closed’) as m where m.salary > 5000
