Cho, Joonmyun 19-1-8
Object-oriented Database System
Object-oriented Database System
Concepts
Overview of the “ObjectStore” System
Object-oriented Database System
Concepts
Engineering design and manufacturing (CAD/CAM, CIM), image and graphics databases, scientific database, geographic information systems, multimedia database, … These newer applications have requirements and characteristics that differ from those of traditional business applications, including more complex structure for objects, longer-duration transactions, new data types for storing images or large textual items, and the need to define nonstandard application-specific operation.
Consider objects that are two-dimensional bitmap images. Suppose that the application needs to select from a collection of such objects only those that include a certain pattern. In this case, the user must provide the pattern recognition program as a method on objects of the bitmap type Unstructured Complex Object
Objects in an OO programming language exist only during program execution. An OO database provides capabilities so that objects can be created to exist permanently, or persist, and be shared by numerous programs. Hence, OO database store persistent objects permanently on secondary storage, and allow the sharing of these objects among multiple programs and applications
It is customary for an OODBMS to be closely coupled with an OO programming language. Not all objects are meant to be stored permanently in the database. Transient objects exist in the executing program and disappear once the program terminates. The typical mechanism for persistence involves either giving an object a unique persistent name through which it can be retrieved by this and other programs or making the object reachable from some persistent object.
Encalpsulation of operations, methods
The concepts of information hiding and encapsulation are applied to database objects. In traditional database, a number of standard database operations are applicable to objects of all types. For example, the operations for selecting, inserting, deleting, and modifying tuples are generic and may be applied to any type of relation in the database.
In OO database, the internal structure of the object is hidden, and the object is only accessible through a number of predefined operations.
For database applications, the requirement that all objects be completely encapsulated is too stringent. One way of relaxing this requirement is to divide the structure of an object into visible and hidden attributes(variables), Visible attributes may be directly accessed for reading by external operators, or by a high-level query language.
Object Identity
One goal of OO database is to maintain a direct correspondence between real-world and database objects so that objects do not lose their integrity and identity and can easily be identified and operated upon. Hence OO database provide a unique system-generated object identifier (OID) for each object. In the relational model, if the value of the primary key is changed, the tuple will have a new identity, even though if may still represent the same real-world object. Alternatively, a real-world object may possess different keys in different relations, making it difficult to ascertain that the keys do indeed stand for the same object.
Representing Relationlship
One problem in OO database systems involves representing relationships among objects. The insistence on complete encapsulation in early OO data model led to the argument that relationships should not be explicitly represented but instead should be described by defining appropriate methods that locate related objects.
But, many OO data models now allow the representation of relationships via references -that is, by placing the OIDs of related objects within an object itself[Memo1].
Overview of the “ObjectStore” System
Data Definition in ObjcetStore
ObjectSore can use the C++ class declarations as its data definition language
ObjectStore’s extended C++ compiler supports inverse relationship declarationspermitting the specification of inverse attributes that represent a binary relationship. ObjectStore then keeps the relationship consistent automatically.
Data Manipulation in ObjectStore
ObjectStore uses C++ to develop its applications
ObjectStore also has a query facility, which can be used to select a set of objects from a collection by specifying a selection condition. Query language [Memo2]statements can be embedded within a C++ program, and can be considered a means of associative high-level access to select objects that avoids the need to create an explicit looping construct.
Example
extern database* univ_db;
class Person;
class Faculty: public Person
{
float salary;
…
os_Set<Department*> belongs_to inverse_member Department::members;
os_Set<Grant*> grants;
…
void promote_faculty();
Faculty(char s[9])
{
ssn = new(univ_db) char[9];
strcpy(ssn, s);
}
…
}
class Department
{
char* dname
os_Set<Faculty*> members inverse_member Faculty::belongs_to;
…
void add_major(student* s);
…
}
main()
{
database* univ_db = database::open(“/database/univ”);
trnasaction::begin();
/* create two persistent sets to hold all Faculty and all Department objects [Memo3]*/
os_Set<Faculty*> &all_depts = os_Set<Department*>::create(univ_db);
os_Set<Department*> &all_depts = os_Set<Department*>::create(univ_db);
/* create a new Faculty object and a new Department object using the consturctors */
Faculty* f = new(univ_db) Faculty(“123456789”);
Department* d = new(univ_db) Department(“Computer Science”);
/* relate the objects by invoking the appropriate method */
d->add_faculty(f);
/* add the objects to their persistent sets */
all_faculty.insert(f);
all_depts.insert(d);
transaction::commit();
}
1/4
[Memo1]
“ObjectStore”의 경우 relationship facilities를 별도로 제공한다.
[Memo2]
ex) os_Set<Facility*& asst_profs = all_faculty[:rank == ‘AssistantProfessor’:]
[Memo3]
The typical mechanism for persistence involves either giving an object a unique persistent name through which it can be retrieved by this and other programs or making the object reachable from some persistent object.