Object database standards, languages and design

OBJECT DATABASE STANDARDS, LANGUAGES AND DESIGN ADBMS By: Dabbal S. Mahara 2018

Why database standards? • Having a standard for a particular type of database system is very important because of following reasons: 1. It provides support for portability of database applications. Portability is generally defined as the capability to execute a particular application program on different systems with minimal modifications to the program itself. 2. It helps to achieve interoperability. It generally refers to the ability of an application to access multiple distinct systems. In terms of database systems, this means that same application program may access some data stored under one ODBMS package, and other data store under another package. 3. It allow customers to compare commercial products more easily by determining which parts of the standards are 2

ODMG • ODMG ( Object Data Management Group) is a consortium of ODBMS vendors. • It proposed a standard for ODBMS in 1993 as ODMG 1.0, in 1995 ODMG 2.0 and in 2000 ODMG 3.0. • The ODMG 3.0 standard is made up of several parts: ‣ Object model ‣ Object definition language (ODL) ‣ Object query language (OQL) ‣ Binding to OOP languages 3

The Object Model The Object Model specifies the constructs that are supported by an ODMS: • The basic modeling primitives are the object and the literal. Each object has a unique identifier. A literal has no identifier. • Objects and literals can be categorized by their types. All elements of a given type have a common range of states (i.e., the same set of properties) and common behavior (i.e., the same set of defined operations). • An object is sometimes referred to as an instance of its type. • The state of an object is defined by the values it carries for a set of properties. These properties can be attributes of the object itself or relationships between the object and one or more other objects. 4

The Object Model • The behavior of an object is defined by the set of operations that can be executed on or by the object. • Operations may have a list of input and output parameters, each with a specified type. Each operation may also return a typed result. • An ODBMS stores objects, enabling them to be shared by multiple users and applications. These objects are called persistent objects. • An ODBMS is based on a schema that is defined in ODL and contains instances of the types defined by its schema. 5

Types: Specifications and Implementations • There are two aspects to the definition of a type. A type has an external specification and one or more implementations. • The specification defines the aspects that are visible to users of the type: the operations that can be invoked on its instances, the properties, or state variables, whose values can be accessed, and any exceptions that can be raised by its operations. • A type’s implementation defines the internal aspects of the objects of the type: the implementation of the type’s operations and other internal details. The implementation of a type is determined by a language binding. 6

Types: Specifications and Implementations • An interface definition is a specification that defines only the abstract behavior of an object type. • A class definition is a specification that defines the abstract behavior and abstract state of an object type. • A class is an extended interface with information for ODMS schema definition. • A literal definition defines only the abstract state of a literal type. 7

Types: Specifications and Implementations • For example, interface Employee defines only the abstract behavior of Employee objects. Class Person defines both the abstract behavior and the abstract state of Person objects. • Finally, the struct Complex defines only the abstract state of Complex number literals. In addition to the struct definition and the primitive literal datatypes (boolean, char, short, long, float, double, octet, and string), ODL defines declarations for user-defined collection, union, and enumeration literal types. • interface Employee {...}; class Person {...}; struct Complex {float re; float im; }; 8

Types: Specifications and Implementations 9

ODMG Objects and Literals • The basic building blocks of the object model are ‣ Objects ‣ Literals • The main difference between the two is that an object has both an object identifier and a state (current value), where as a literal has a value but no identifier. • In either case, value can have a complex structure. 10

Literals • Literals do not have their own identifiers and cannot stand alone as objects; they are embedded in objects and cannot be individually referenced. • The value of a literal cannot change. • Examples of literal values are the numbers 7 and 3.141596, the characters A and B, and the strings Fred and April 1. • The Object Model supports the following three literal types: ‣ atomic literal ‣ collection literal ‣ structured literal 11

Literal Types • Atomic Literals Correspond to the values of basic data types. That is, numbers, characters, Boolean values etc are examples of atomic literal types. • Structured Literals Correspond to the values constructed by tuple constructor. They include: date, time, interval and timestamp as built-in structures and any other user defined structures. • Collection Literals The ODMG Object Model supports collection literals of the following types: set<t> , bag<t>, list<t>, array<t>, dictionary<t, v>, where t is a type of objects or values in the collection 12

Objects • An object has four characteristics 1. Identifier: unique system-wide identifier 2. Name: unique within a particular database and/or program; it is optional 3. Lifetime: persistent vs. transient 4. Structure: specifies how object is constructed by the type constructor and whether it is an atomic object or collection object. 13

Object Identifiers • An object can always be distinguished from all other objects within its storage domain by using object identifier. • An object retains the same object identifier for its entire lifetime. Thus, the value of an object’s identifier will never change. • The object remains the same object, even if its attribute values or relationships change. • Object identifiers are generated by the ODMS, not by applications. 14

Object Names • In addition to being assigned an object identifier by the ODMS, an object may be given one or more names that are meaningful to the programmer or end user. • The application can refer at its convenience to an object by name; the ODMS applies the mapping function to determine the object identifier that locates the desired object. 15

Object Lifetime • The lifetime of an object determines how the memory and storage allocated to the object are managed. • Two lifetimes are supported in the Object Model: ‣ transient ‣ persistent • An object whose lifetime is transient, is allocated memory that is managed by the programming language runtime system. When the process terminates, the memory is de-allocated. • An object whose lifetime is persistent, is allocated memory and storage managed by the ODMS runtime system. These objects continue to exist after the procedure or process that creates them terminates. 16

Object Structure • The structure of object can be either atomic or not, in which case the object is composed of other objects. • An atomic object type is user-defined. There are no built-in atomic object types included in the ODMG Object Model. • In the ODMG Object Model, instances of collection objects are composed of distinct elements, each of which can be an instance of an atomic type, another collection, or a literal type. 17

Collection Objects • An important distinguishing characteristic of a collection is that all the elements of the collection must be of the same type. • They are either all the same atomic type, or all the same type of collection, or all the same type of literal. • The collections supported by the ODMG Object Model include: ‣ Set<t>: A Set object is an unordered collection of elements, with no duplicates allowed. ‣ Bag<t>: A Bag object is an unordered collection of elements that may contain duplicates. ‣ List<t>: A List object is an ordered collection of elements. ‣ Array<t> : An Array object is a dynamically sized, ordered collection of elements that can be located by position. ‣ Dictionary<t,v>: A Dictionary object is an unordered sequence of key-value pairs with no duplicate keys. • Each of these is a type generator, parameterized by the type shown within the angle brackets. 18

Structured Object • All structured objects support the Object ODL interface. • The ODMG Object Model defines the following structured objects: ‣ Date ‣ Interval ‣ Time ‣ Timestamp ‣ User defined structured objects • Example: user defined structured object struct Address { string dorm_name; string room_no; }; attribute Address dorm_address; 19

ODMG Interface • An interface is a specification of the abstract behavior of an object type. • It is a signature for the persistent object. Interface tells external world how to interact with an object. That is, an interface describes the interface of types of objects: their visible attributes, relationships and operations. • Interfaces are non-instantiable but they serve to define operations that can be inherited by the user-defined objects for a particular application. • State properties of an interface (i.e., its attributes and relationships) cannot be inherited. 20

Object Inheritance Hierarchy: Built-in Interfaces of ODMG 21

Object Interface • In the object model, all the objects inherit the basic interface Object. • Typical interface of an object of ODMG showing operation declarations is given below: interface Object { ... Boolean same_as(in object obj); // compares the object’s identity to another object object copy(); // create a new copy of the object void delete(); // deletes the object }; 22

Collection Interface • Collection interface: Any collection object inherits the basic collection interface. • This interface provides following operations: • cardinality() // returns no. of objects in the collection • is_empty() // returns true if collection is empty • insert_element() // inserts an element from the collection • remove_element() // removes an element from the collection • contains_element()// returns true if an element is in the collection • create_iterator() // creates an iterator object for the collection object 23

Iterator Interface • The iterator interface defines the operations for iterator object for the collection object. • The iterator object iterate over each element in the collection. • The interface iterator is: interface Iterator{ exception NoMoreElements(); ..... boolean is_stable(); boolean at_end(); void reset(); any get_element() raises(NoMoreElements); void next_position() rasises(NoMoreElements); ....}; 24

Collection Types • Collection objects are further specialized into types like a set, list, bag, array, and dictionary. • All these inherit the Collection Interface. • Set(t) : This interface is used to allow objects such that value of the object is a set of elements of type t. • Bag(t): interface used to have objects with the duplicate elements in the collection. • List(t): interface has an ordered collection of elements of type t. • Array(t): similar to list but has fixed number of elements • Dictionary(k,v): allows to have objects with collection of association <k,v> where k is kye and v is value. 25

Set Interface • For example, interface Set provides following operations: • create_union() // returns an object of type set(t) by union of two objects • create_difference() • is_subset_of() // returns TRUE if subset relation holds • is_superset_of() • is_proper_subset_of() • Note: for Bag, List, Array and Dictionary refer to book ( Elmasri and Navathe) 26

Atomic Objects • Any user defined object that is not a collection object is called an atomic object. • Atomic objects are defined via keyword class in ODL. • Most of such objects will be structured objects. • An example: class Employee (extent all_emplyees key ssn) { attribute string name; attribute string ssn; attribute short age; relationship Dept works_for ; void reassign(in string new_name); } 27

Interfaces and Behavior Inheritance • In ODMG, two types of inheritance relationships exist. • An interface is a specification of the abstract behavior of an object type, which specifies the operation signatures. • Interfaces are noninstantiable – that is, one cannot create objects that correspond to an interface definition. • They are mainly used to specify abstract operations that can be inherited by classes or by other interfaces. • Subtyping pertains to the inheritance of behavior only and it is specified by colon ( : ). 28

Classes and EXTENDS inheritance • A class is a specification of both the abstract behavior and abstract state of an object type, and is instantiable. • State of an object has two kinds of properties: attribute and relationship. • An attribute is of one type. • A relationship is defined between two types, each of which must have instances that are referenceable by object identifiers. • The ODMG Object Model defines an EXTENDS for the inheritance of state and behavior. • The EXTENDS relationship is a single inheritance between two classes whereby the subordinate class inherits all of the properties and all of the behavior of the class that it extends. 29

Example  class Person { attribute string name; attribute Date birthDate; };  // in the following, the colon denotes the behavior inheritance // the extends denotes the EXTENDS inheritance class EmployeePerson extends Person : Employee { attribute Date hireDate; attribute Currency payRate; relationship Manager boss inverse Manager :: subordinates; }; class ManagerPerson extends EmployeePerson : Manager { relationship set<Employee> subordinates inverse Employee :: boss; }; 30 Note: inverse indicates bidirectional relationship.

Extents • The extent of a type is the set of all instances of the type within a particular ODMS. • If an object is an instance of type A, then it will necessarily be a member of the extent of A. • If type A is a subtype of type B, then the extent of A is a subset of the extent of B. • The ODMS schema designer can decide whether the system should automatically maintain the extent of each type. • In some cases, the individual instances of a type in the extent can be uniquely identified by the values they carry for some property or set of properties. These identifying properties are called keys. • The scope of uniqueness is the extent of the type; thus, a type must have an extent to have a key. 31

Example class Employee (extent all_emplyees key ssn) { attribute string name; attribute string ssn; attribute short age; relationship Dept works_for; void reassign(in string new_name); }; 32

ObjectFactory • A factory object is used to generate individual objects via its operations. • A factory object basically provides the constructor operations for new objects. • An example: interface ObjectFactory { Object new (); }; • new() returns new objects with an object_id • One can create their own factory interface by inheriting the above interface 33

Object Definition Language • ODL is a standardized language for specifying the structure of databases in object-oriented terms. • It is an extension of IDL (Interface Description Language), a component of CORBA (Common Object Request Broker Architecture). The latter is a standard for distributed, object-oriented computing. • The Object Definition Language is a specification language ( Design Language) used to define the specifications of object types that conform to the ODMG Object Model. • Can be used like E/R as a preliminary design for a relational DB. • ODL is independent of any programming language. • ODL is not used for database manipulation. 34

Properties of Objects • The properties of objects in a class must be the same. When programming in an object-oriented language, we sometimes think of objects as records, like that suggested by Figure (a). Objects have fields or slots in which values are placed. These values may be of general types such as integers, strings, or arrays, or they may be references to other objects. • When specifying the design of ODL classes, we explain properties of three kinds; • Attributes, which are values associated with the object. We discuss the legal types of ODL attributes in "Types in ODL". • Relationships, which are connections between the object at hand and another object or objects. • Methods, which are functions that may be applied to objects of the class. • Attributes, relationships, and methods are collectively referred to as 36

Object Query Language • OQL is DMG’s query language. • OQL works closely with programming languages such as C++. • Embedded OQL statements return objects that are compatible with the type system of the host language. • OQL’s syntax is similar to SQL with additional features for objects. 43

Difference between ODB and RDB Design 1. One of the main difference between ODB and RDB design is how relationships are handled. • In RDB relationships among tuples are specified by attributes with matching values. These can be considered as value references and specified via foreign key, which are values of primary key attributes in tuples of the referencing relation. These are limited to being single- valued in each record. • In ODB, relationships are typically handled by having relationship properties or reference attributes that include OID(s) of the related objects. These can be considered as OID references to the related objects. Both single references and collections of references are allowed. 48

ODB Vs RDB Design • Mapping binary relationships that contain attributes is not straightforward in ODBs, since the designer must choose in which direction the attributes should be included. If the attributes are included in both directions, then redundancy in storage will exist and may lead to inconsistent data. 2. Another major area of difference between ODB and RDB design is how inheritance is handled. • In ODB, these structures are built into the model, so the mapping is achieved by using the inheritance constructs, such as derived (:) and extends. • In relational design, there are several options to choose from since no built-in construct exists for inheritance in the basic relational 49

ODB Vs RDB Design 3. The third major difference is that specification of operations, • In ODB design, it is necessary to specify the operations early on in the design since they are part of the class specifications. • Although it is important to specify operations during the design phase for all types of databases, it may be delayed in RDB design as it is not strictly required until the implementation phase. • There is a philosophical difference between the relational model and the object model of data in terms of behavioral specification. The relational model does not mandate the database designers to predefine a set of valid behaviors or operations, whereas this is a tacit requirement in the object model. 50

Mapping an EER Schema to an ODB Schema • Mapping EER schemas into ODB schemas is relatively simple especially since ODB schemas provide support for inheritance relationships. • Once mapping has been completed, operations must be added to ODB schemas since EER schemas do not include an specification of operations 51

Step -1. • Create an ODL class for each EER entity type or subclass ‣ Multi-valued attributes are declared by sets, bags or lists constructors ‣ Composite attributes are mapped into tuple constructors 52 EER to OO Mapping

EER to OO Mapping Step - 2 • Add relationship properties or reference attributes for each binary relationship into the ODL classes that participate in the relationship. ‣ Relationship cardinality: single-valued for 1:1 and N:1 directions; set- valued for 1:N and M:N directions ‣ Relationship attributes: create via tuple constructors 53

EER to OO mapping Step - 3 • Include appropriate operations for each class. These are not available from the EER schema and must be added to the database design by referring to the original requirements. • Corresponding constructor and destructor operations must also be added 54

EER to OO Mapping Step - 4 • Specify inheritance relationships via extends clause: ‣ An ODL class that corresponds to a sub-class in the EER schema inherits the types and methods of its super-class in the ODL schemas ‣ Its specific (non-inherited) attributes, relationship references, and operations are specified, as discussed in steps 1, 2, and 3. 55

EER to OO Mapping Step - 5 • Weak entity types can be mapped in the same way as regular entity types. • Attributes are mapped as discussed in steps 1 and 2. • Weak entities that do not participate in any relationships except their identifying relationship may alternatively be presented as composite multi-valued attribute of the owner entity type. • The attributes of the weak entity are included in the struct<... > construct, which corresponds to a tuple constructor. 56

EER to OO Mapping Step - 6 • Map categories (union types) to ODL ‣ The process is not straightforward. ‣ May follow the same mapping used for EER-to-relational mapping: ‣ Declare a class to represent the category ‣ Define 1:1 relationships between the category and each of its super-classes 57

EER to OO Mapping Step - 7 • Map n-ary relationships whose degree is greater than 2 ‣ Each relationship is mapped into a separate class with appropriate reference to each participating class 58

EER to ODB : Example See Chapter 21 of the book. 59

Exercise 60 1. What is the difference between an object and a literal in the object oriented data model (OODM) ? 2. What are the main difference between designing a relational database and an object database? 3. What are the differences and similarities between objects and literals in the ODMG object model? 4. Describe the steps of the algorithm for object database design by EER-to-OO mapping. 5. Differentiate between: i. Interface and Class ii. Extents and Extends iii. Atomic Object and Collection Object iv. OID and Key v. Persistent Object and Transient Object

Object database standards, languages and design

More Related Content

What's hot

Similar to Object database standards, languages and design

More from Dabbal Singh Mahara

Recently uploaded

Object database standards, languages and design