Escolar Documentos
Profissional Documentos
Cultura Documentos
Ye-In Chang, Shih-Hao Jair, and Hong-Nian Chen Department of Applied Mathematics National Sun Yat-Sen University Kaohsiung, Taiwan, R.O.C.
ABSTRACT
A multimedia database (denoted as MMDB) management system manages multimedia data, where multimedia data is de ned as any combination of data in the form of text, images, animation, sound and video. Due to these complex combination of di erent types of data, and many special properties of multimedia applications, traditional record-based DBMS techniques are not e ective and not powerful enough to support those multimedia applications. In this paper, we design and implement a QBOE (Query-By-Object-Example) query language for multimedia database systems. Our system is based on an object-oriented model. The query language is called Query-By-Object-Example, since either DDL (Data De nition Language) or DML (Data Manipulation language) is through an object example. In the part of DDL, the user can specify the prototype of a multimedia application, including the speci c keywords for the application and related operations. In the part of DML, the user can access data by contents or keywords which are speci ed in attributes.
Key words: data modeling, database management systems, multimedia database management systems, query languages
I. Introduction
A multimedia database (denoted as MMDB) management system manages multimedia data, where multimedia data is de ned as any combination of data in the form of text, images, animation, sound and video (Berra et al., 1993 Grosky, 1994 O'Docherty and Daskalakis, 1991). Due to these complex combination of di erent types of data, and many special properties of multimedia applications, traditional record-based DBMS techniques are not e ective and not powerful enough to support those multimedia applications. Therefore, di erent models to describe the properties of data and the relationship (and constrains) among data, di erent storage structure techniques and query languages for e cient data access, di erent transaction management techniques (including concurrency control and recovery) and version management mechanisms for reliable data sharing are required (Christodoulakis et al., 1986 Huang and Lo, 1994 Little and Ghafoor, 1990, 1993 Oomoto and Tanaka, 1993). In the part of data modeling, multimedia databases require a data model that allows a very natural and exible de nition and evolution of the schema which can represent the composition of compound document and capture the complex relationships among parts of compound data. The traditional well-known record-based relational data model does not provide the possibility of directly modeling complex data. Moreover, many complex relationships among data, for example, instantiation, aggregation and generalization, can not be well de ned in the relational data model. Furthermore, the relational data model does not provide mechanisms to associate data behavior with data de nitions at schema level. An object-oriented data model not only provides great expressive power to describe data and to de ne complex relationships among data, it but also provides mechanisms for behavioral abstraction. Therefore, an object-oriented approach to modeling multimedia data has been studied largely in past years (Ishikawa et al., 1993 Woelk, 1986, 1997). In the part of query languages for e cient data access, multimedia databases require a userfriendly query language that can retrieve data by content, by keywords or by relationships. The major characteristics of a query language are its high-levelness, declaractiveness, e ciency and application independence. In this paper, we design and implement a QBOE (Query-By-Object-Example) query language for multimedia database systems. Our system is based on an object-oriented model. In this version of QBOE MMDB, we consider only three types of media: text, graph and image. The query language is called Query-By-Object-Example, since either DDL (Data De nition Language) or DML (Data Manipulation language) is through an object example. In the part of DDL, the user can specify the prototype of a multimedia application, including the speci c keywords for the application and related operations. In the part of DML, the user can access data by contents or keywords which are speci ed in attributes. Based on well-trained knowledge about X-lib (for X window systems) (Nye, 1992), database systems and image processing, we have developed a user-friendly interface for QBOE MMDB (Jair, 1995). The rest of the paper is organized as follows. In Section 2, we describe the objectoriented model for our QBOE (Query-By-Object-Example) multimedia database system.
We use a multimedia poster as an example. We also show the logical structure of this example. In Section 3, we present the DDL (Data-De nition-Language) and DML (DataManipulation-Language) of our QBOE multimedia database system. In Section 4, we describe the implementation of our QBOE query language for multimedia database systems. Finally, Section 5 gives the conclusion.
The core object-oriented concepts include the following items (Shah and Wong, 1994): (1) Objects and object identi ers. In an object-oriented system, all real-word entities are represented as objects and each object has a unique identi er. An object may be a simple object or it may contain other objects. (2) Attributes and methods. An object can have one or more attributes and methods, which operate on the values of these attributes. (3) Encapsulation and message passing. External entities cannot directly access the attributes of the object. To access the values of these attributes, messages have to be sent to the object. (4) Classes and instances. Classes provide means to group objects that share the same set of attributes and methods. Objects that belong to a class are called instances of that class. (5) Class hierarchy and inheritance. The classes in an object-oriented systems form a hierarchy (the class hierarchy), where a subclass inherits all the attributes and methods of its superclass(es). Inheritance provides an important means for sharing behavior among related objects.
Figure 1 shows a typical example of a multimedia poster. It contains three kinds of the typical multimedia information: text, drawing and image. In this poster example, Time, Place and Dept. are keywords for a typical poster. The rst line is the topic of the poster. The poster header contains the topic and those key words and related data. The poster body contains a paragraph, a drawing graph, an image, a drawing graph, and a paragraph. The logical data model of this example is described in Figure 2. Note that there are six types of information represented in Figure 2, which are described as follows (Woelk et al., 1986): (1) The connected circles represent the logical parts of the Poster. They are connected to form the aggregation hierarchy. Unshaded circles represent what we might consider to be parts of a template for a Poster. For example, all Posters contain a Poster-Header and a Poster-Body. This can be through of as representing the schema for a Poster. (2) Shaded circles represent the portion of the aggregation
PosterHeader
Poster Body
Topic
TimeLine
By
Time:
Time
Dept.:
DepartName
vi Time: 1995.6.9 13:00 Dept. Applied Mathematics Place: Science 4013 room
hierarchy which is unique to this particular Poster. For example, the Text contained in the Poster-Body of the Poster are unique to this particular Poster. (3) The Squares represent uniformmated intrinsic data such as text, digitized image and complex vector graphics drawings. The Unshaded Squares represent data which is present for every Poster. For example, the word \Time:" will occur in every Poster. (4) The Shaded Squares represent text, image which we might consider to be unique to this particular Poster. For example, the words \1995.6.9 13:00" would only occur on this Poster. (5) The Ovals represent information about the data in the Shaded and Unshaded Squares as well as information about the Shaded and Unshaded Circles of the aggregation hierarchy. For example, all of the text in the Poster is to be displayed in Font-Size = 12. (6) The Rectangles represent operations on the data in the Squares, Circles, and Ovals of the aggregation hierarchy. For example, the Rectangle labelled Draw in Figure 2 contains procedural operations for drawing the drawing part. In Figure 2, a multimedia application is described in terms of diagrams. The diagram is a directed acyclic graph containing nodes and directed arcs. The types of nodes and the legal directed arcs from each type of nodes are shown in Figure 3: token objects representing classes, token objects representing instances, attributes, method objects, and intrinsic data objects (Woelk et al., 1986). The following describes the legal directed arcs which are associated with a token object as shown in Figure 3: (1) Instantiation. Each instance is represented by a token object which has an IS-INSTANCE-OF directed arc to an object. For example, the IS-INSTANCE-OF directed arc between the Poster instance node and the Poster class node in Figure 3 represents instantiation. (2) Generalization. An object class, represented by a token object, can have an IS-TYPE-OF directed arc to another token object representing another object class. (3) Aggregation. In Figure 3, there is a HAS-PARTS directed arc between the Poster-Body instance and the Text instances, the Drawing instances, and the Image instance. (4) Attributes. Each token object has a HAS-ATTRIBUTES arc which points to multiple attributes. An example of an attribute is the Font-Size=12 in Figure 3. (5) Methods. Each token object has a HAS-METHODS arc which points to one or more programs which are stored independently from the token object. Figure 4 and Figure 5 represent the logical data structure of the Poster class and instances, respectively. The MIN and the MAX values specify the minimum number and maximum number of instances of the class which can be contained, respectively.
PosterBody instance
HAS-PART
Drawing
Text
Image
Drawing instance
HAS-DATA
Image instance
HAS-DATA
Drawing instance
HAS-DATA
Text instance
HAS-DATA
1 HAS-METHOD TimeLine draw vi Time-Line instance HAS-PART 3003 3004 3005 3006 3007 HAS-METHOD
CAN-HAVE-PART 1 1 Time
Time:
HAS-DATA
Time: instance
HAS-DATA
Time instance
HAS-DATA
3001
3001
3002
ATTRIBUTE
METHOD OBJECT
100
Poster
Font-size=12
method draw vi
obj-id 200
has-data obj-id
has-attributes
has-method
210 211
120 (Time-Line) 121 (Text) 122 (Image) 123 (Drawing) 123 (Drawing) 121 (Text) 130 (Time:) 131 (Time)
230 (Time:) 231 (Time) 3003 3004 3005 3006 3007 3001 3002
For the commercial purpose, the most important communication channel between human and machine is the user interface, especially in growth of the nonprofessional users of database system. Therefore, the design of the user interface of database system must let users do the least thing and get the most pro t. When a user enters the system, there are two options: query and create. To de ne a Poster class, a user rst chooses the create option. Next, the system will ask the user to enter an object name. For each object, the system will ask for some more information: Class Type, Part Number, Data, Attribute and Method as shown in Figure 6. Those elds must be lled with an integer which means the number of related information. For example, in Figure 6, the user enters 2 in the Part Number eld, which means that the Poster object contain two parts. The system will ask the user to input those two children names one at a time. Figure 7 shows an example to input the child Poster-Header. Moreover, for each child, the user has to specify the low bound and upper bound of the number of occurrence of that child in Min Part and Max Part, respectively. Since each
Figure 9: Speci cation of data in object Time:. Poster can contain one and only one Poster-Header, those value are all 1's as shown in Figure 7. For the Poster object, the user can also specify some attributes. In this example, as shown in Figure 2, the Poster object has a Font-Size = 12 attribute. In the same way, Figure 8 shows the process after four parts of Poster-Header have been speci ed. In the part of Post-Body, it can contain Text, Drawing and Image. The number of those parts can be from 0 to N (i.e., no limitation). Therefore, the user inputs 0 and N in Min Part and Max Part, respectively. Since in a standard Poster object, there are always some keywords like Time, Dept. and Place. Therefore, we also support users to input those keywords as built-in data for each Poster object. Figure 9 shows the way to specify the number of built-in data. After that, the user can input a le name as the input data. If the le exists, the system will load the data stored in the le and show it in the screen. If the le does not exist, the system will ask the user to choose the type of data: Text, Drawing or Image, and will invoke related editor as shown in Figure 10. For example, since Time is of text type, the system will invoke \vi" as shown in Figure 11. The nal result is shown in Figure 12.
10
Figure 14: The Poster class hierarchy. For some object, there may be some related methods with it. For example, as shown in Figure 2, there is a Draw method for the Drawing object. In the same way, after specifying the number of methods in the Method eld , the system will ask the user to input a method name for the Drawing object. Finally, Figure 13 shows the nal structure of object Poster.
We have described the Create function in the previous section and have created a new Poster schema. Next, we will show how the other function { Query { works. After we choose the Query function, the system will pop up a window that shows all of the functions that the system provides: Insert, Delete, Select, and Modify. After we choose the Insert function, a pop-up window appears, which asks the user to enter an object class name. After Poster is entered, the system returns the Poster class hierarchy as shown in Figure 14, where the circle nodes mean the data which has been created by DDL. Every instance of the Poster class shares those data objects.
11
Figure 15: The control table and the output window. After the addNewOne function is chosen, two windows pop up at the same time as shown in Figure 15. The upper one is called the control table and the lower one is called the output window. The control table shows the objects which you can edit on the output window at this moment. After we choose the Poster-Header, the objects shown in the control table is replaced by the children of the Poster-Header. At this time, a new rectangle box shows up in the output window, which represents the position where any of these four objects: Topic, Time-Line, By and Place-Line, can place. The rectangle can be moved to any place as we want in the output window. After we move the rectangle to a certain position, we can start to enter data. For example, after we choose the Topic object, a pop-up window which inquires the user to input data appears again. Then, another window appears to ask the user to input the le name. After examine is entered, the system will ask for the data type of the speci ed le name. In this case, Text is chosen. Assume that the examine le dose not exist therefore, a test editor \vi" is invoked. After we edit the le and exit \vi", the le is ready and is copied to the output window as shown in Figure 16. Next, the system will ask the user to input a keyword for the data as shown in Figure 17. (Note that if the examine le already exist, then the contents of the le will directly show up in the output window without invoking the text editor \vi".) In the same way, when other object is chosen, the system will rst ask for a le name, and then the data type of the speci ed le name. If the le already exists, the le is copied to the position where the new rectangle appears in the output window. If the le does not exist, the related editor is invoked. Consider a drawing object is chosen. First, the system shows a window to input the le name. Then, the data type Drawing is chosen. Assume that the le does not exist therefore, the drawing editor is invoked as shown in Figure
12
13
18. This drawing editor is implemented by ourself. (Note that the reason why we do not use an existing drawing editor, for example, xfig, is that we do not realize the internal representation of a gure in xfig.) Figure 19 shows the output window after the drawing le is loaded. Finally, Figure 20 shows the output window after the insertion is nished. This is the example that we have used through the paper. Let us consider the case of data selection. First, the system will ask for an object name. Then the object hierarchy appears and two selection options, contain-based and keywordbased, are shown up on the left upper corner. After the user chooses the Topic object, the word Topic will appear on the bottom line of the screen. The user then chooses the contain-based function. At this time, an empty box will appear on the left upper corner. In this example, the user types \Jair" in the box. After that, a sentence (Topic CONTAINS "Jair") appears on the bottom line of the screen as shown in Figure 21. Now, the user has entered the condition which is equivalent to a SQL statement (select * from Poster where Topic CONTAINS "Jair"). The result is shown in Figure 1. Next, let us see an example of a keyword-based query. After the user chooses the Drawing object, the word Drawing will appear on the bottom line of the screen. The user then chooses the keyword-based function. At that time, an empty box will appear on the left upper corner. In this example, the user types "pain" in the box. After that, a sentence (Drawing: KEYWORD = "pain") appears on the bottom line of the screen as shown in Figure 22. Now, the user has entered the condition which is equivalent to a SQL statement (select * from Poster where Drawing: KEYWORD = "pain"). The same result is obtained. To implement the SQL statement (select Text from Poster where Topic CONTAINS "Jair"), the user can move the cursor to the Text part which the user is interested in and clicks the button one time, which results in a new Text window showing up. In the same way, the user can move the cursor to the Drawing part or the Image part, and clicks the button one time to open a new Drawing window or a new Image window. Figure 23 shows that the output window, the Text window, the Drawing window and Image window can appear at the same time. Moreover, we can extend our system to handle a query which contains AND, OR logical operations for more complex queries. We also can extend our system to handle a set of results by providing Previous and Next functions to browse a set of results. For the Delete function, the user follows the way of using the Select Function to nd out what he (she) wants to delete. After the data shows up, the system will ask the user to con rm his (her) choice as shown in Figure 24. For the Update function, there are four options: modify, move, insert and delete. Those four options operate on a single object at a time. First, the user also follows the way of using the Select function to nd out what he (she) wants to update. After the data shows up, the user can move the cursor to the part which he (she) wants to modify by choosing the modify option. After the user clicks the part, the related Text or Drawing or Image windows will occur. Take the Drawing window as an example, the user then can enter the drawing editor \MyDraw" environment to modify the drawing part. After the user exists the drawing editor, the updated le will copy to the output window. Figures 25, 26 and
14
15
16
17
Figure 24: An example of deleting the whole Poster instance. 27 show such an example. That is, the updated result shows up. When the delete option is chosen, the selected object will be deleted one at a time as shown in Figure 28. When the move option is chosen, the selected object can be moved to any place in the output window as shown in Figure 29. When the insert option is chosen, a new object can be inserted as shown in Figure 30 by pressing the Yes button. Then, the system will ask the user to choose the type of the data as following the steps of the Insert function described before. The related editor will be invoked if it is necessary. Figure 31 shows the result of the single object insertion. The BNF grammar of the QBOE language is shown in Figure 32, which is similar to the one proposed by Kau and Tseng (1994).
18
19
20
21
<S> ::= <A> ::= <R> ::= <C> ::= <C1>::= <E> ::= <L> ::=
SELECT <A> FROM <R> WHERE <C> <attribute_name> | * <class_name> (<C1> ( AND | OR ) <C> | <C1> ) ("(" <C> ")" | <E> ) <L> ("=" | "<" | ">" | CONTAINS | : KEYWORD = ) <L> <string>
Figure 32: The BNF grammar of the QBOE language (the selection part).
obj-id
class-name
has-data obj-id
has-attributes
has-methods
22
struct PARTf int min int max CLASS *object char *objName int objID
g
23
End of classFile No No
Yes
return NULL
stop
className = X
Yes
return objectID
stop
Yes End
Yes Yes
PartCount = 0
No stop i=1
No
constructClassHierarchy(Part.objID)
i++
24
25
All class objects that have been created are saved in the classFile, as shown in Figure 35. The rst columns are the objectID. The following ve columns are the additional elements which are described above. Let's examine the 4th row in Figure 35 the 3rd column of that row has a value 2. It indicates that the object has two children. So, the numbers following Time-Line describe the children's characteristic. The rst number indicates that at least one child exists, and the second number indicates the maximum number of children of this class. The third number is the ID of the rst child. Figures 36 and 37 shows the owcharts of constructing a class hierarchy. First, the system scans the classFile le to search the assigned class. If the named object does not exist in the classFile le, then NULL is turned. If the named object is in the classFile le, then the related objectID is returned. Next, the system recursive calls the function constructClassHierarchy to construct the children of the assigned objectID. In our example, it is 23000 for the Poster object. The children of the Poster is saved in the PART structure. Figure 38 shows the data structure of an instance of a class object. Figure 39 shows an example of the instance le. All instances of Poster class is stored in this PosterInstances le. Let's examine the 3rd row in Figure 39. The third column of that row has a value 1, which indicates that the object has a data le whose name is following the object identi er 10250, i.e., time. The 6th column of that row has a value 1, which indicates that the object has a keyword whose content is following the data le name, i.e., examtime. The 5th column of that row has a value 5, which indicates that the object has 5 more attributes to be recorded, i.e., type, upperleftX , upperleftY , lowerrightX , lowerrightY . Following the keyword content, there is a string type=X , which indicates that the data is of type text, drawing, image and none of the above for X =1, 2, 3, 0, respectively. The next four strings record the coordinates of the upper left corner and the bottom right corner of the data shown in the output window. For the type of contain-based selection, let us take (select * from Poster where Topic CONTAINS "Jair") shown in Figure 21 as an example. First, we search the Poster class hierarchy constructed by following the owcharts shown in Figures 36 and 37 to nd the objectID of Topic, which is 15570. Second, we search all the data les recorded in dataList which have classID = 15570 in the PosterInstances le to see whether they contain a string "Jair". In this example, the le name is examine. Since there may exist many instances of Poster class, to speed up such a search for those data le names, we can create a le classID-dataList-objectID to record only classID, dataList and objectID of type text (i.e., type = 1) when data of type text is inserted, and then create an index on classID for this le. Note that for this version of QBOE MMDB, we support data access by contents for data of type text only. In this case, we nd that le examine contains "Jair". Third, after we nd out the le which contains the required contents, we then have to nd out the objectID which contains such a le from the classID-dataList-objectID le. In this case, it is 684. Forth, we have to nd out the objectID of the root node of the Poster instance hierarchy which contains a leaf node with objectID = 684. That is, in the object-oriented data model, for such a Poster aggregation hierarchy, we want to nd an answer for a nested predicate Poster.Poster-Header.Topic.objectID = 684 (which is expressed in a path expression). There have been several index organization proposed to support object-oriented query languages,
26
including multiindex (Maier and Stein, 1986), join index (Valduriez, 1987), nested index (Berstino and Kim, 1989), path index (Berstino and Kim, 1989), and full index (Lee et al., 1996). Among them, nested index provides a direct association between an ending object and the corresponding starting object along a path in the given aggregation hierarchy. Therefore, we can create a nested index for the Poster instances and e ciently nd out the objectID of the root, which is 682. Finally, based on the objectID of the root, we can construct the required Poster instance by following a similar owchart shown in Figure 37. For the type of keyword-based selection, let us take (select * from Poster where Drawing : KEYWORD = "pain") shown in Figure 22 as an example. First, we search the Poster class hierarchy to nd the objectID of Drawing, which is 28810. Second, we search the PosterInstances le to nd out whether there exists a keyword = "pain" (recorded in keywordList) which has classID = 28810. To speed up this search, for each data type (text, drawing and image), we create a le classID-keywordList-objectID to record only objectID, keywordList and objectID when data is inserted, and then create an index on classID for this le. In this case, we nd that objectID = 696 of classID 28810 (Drawing) has a key = "pain". Third, by making use of the nested index for the nested predicate Poster-PosterBody.Drawing.objectID = 696, we nd out the objectID of the root, which is 682. Finally, based on the objectID of the root, we can construct the required Poster instance. (Note that if more then one instances are found, we collect the objectID of the roots together and display one instance at a time.)
V. Conclusion
In this paper, we have designed and implemented a QBOE (Query-By-Object-Example) query language for multimedia database systems. Our system is based on an object-oriented model. In this version of QBOE MMDB, we have considered only three types of media: text, graph and image. The query language is called Query-By-Object-Example, since either DDL (Data De nition Language) or DML (Data Manipulation language) is through an object example, In the part of DDL, the user can specify the prototype of a multimedia application, including the speci c keywords for the application and related operations. In the part of DML, the user can access data by contents or keywords which are speci ed in attributes. Based on well-trained knowledge about X-lib, database systems and image processing, we have developed a user-friendly interface for QBOE MMDB. In traditional DBMS, once transaction updates have been committed and permanently installed, the previous values of data usually are discarded. However, advanced multimedia applications, especially design applications, require facilities to maintain data versions, i.e., to keep di erent status of the same data (called historical versions). Moreover, versions can be used to provide a di erent alternatives of the same data (called alternative versions). How to provide mechanisms to manage historical and alternative versions is the further research work.
27
Acknowledgments
This research was supported by the National Science Council of the Republic of China, Grant No. NSC 84-2213-E-110-009.
28
References
Banerjee, J., W. Kim, and K.C. Kim (1988) Queries in object-oriented databases. Proc. of the Int. Conf. on Data Engineering, Austin, TX., U.S.A. Berra, P.B., F. Golshani, R. Mehrotra, and O.R.L. Sheng (1993) Guest editors' introduction multimedia information systems. IEEE Trans. on Knowledge and Data Engineering, 5(4), 545-550. Berstino, E. and W. Kim (1989) Indexing techniques for queries on nested objects. IEEE Trans. on Knowledge and Data Engineering, 1 (2), 196-214. Christodoulakis, S., M. Theodoridou, F. Ho, M. Para and A. Pathria (1986) Multimedia document presentation, information extraction, and document formation in MINOS: a model and a system. ACM Trans. on O ce Information Systems, 4(4), 345-383. Grosky W.I. (1994) Multimedia information systems. IEEE Multimedia, 1(1), 12-24. Huang, C.M. and C.M. Lo (1994) Multimedia e-mail: the evolution approach based on adapters. Software Practice and Experience, 20(9), 785-800. Ishikawa, H., F. Suzuki, F. Kozakura, A. Makinouchi, M. Miyagishima, Y. Izumida, M. Aoshima, and Y. Yamane (1993) The model, language, and implementation of an object-oriented multimedia knowledge base management system. ACM Trans. on Database System, 18(1), 1-50. Jair, S.H. (1995) The implementation of the QBOE multimedia database system. Master Thesis, Dept. of Applied Math., National Sun Yat-Sen Univ., Taiwan, R.O.C. Kau, S.C., J.C.R. Tseng (1994) MQL { a query language for multimedia database. Proc. of IEEE COMSOC Workshop Multimedia '94 Technical Program, Tempe, AZ, U.S.A. Lee, C. I., Y. I. Chang and W. P. Yang (1996) A full index for a class-aggregation hierarchy in objectoriented databases. Proc. of 1996 Euromicro Conf., Prague. Little, T.D.C and A. Ghafoor (1990) Synchronization and storage models for multimedia objects. IEEE Journal on Selected Areas in Comm., 8(3), 413-427. Little, T.D.C. and A. Ghafoor (1993) Interval-based conceptual models for time-dependent multimedia data. IEEE Trans. on Knowledge and Data Engineering, 5(4), 551-563. Maier, D. and J. Stein (1986) Indexing in an object-oriented database. Prof. of IEEE Workshop on Object-Oriented DBMSs, Austin, TX., U.S.A. Nye, A. (1992) Xlib Programming Manual. O'Reilly & Associates, Inc.. O'Docherty, M.H. and C.N. Daskalakis (1991) Multimedia information system - The management and
29
Oomoto, E. and K. Tanaka (1993) OVID: design and implementation of a video-object database system. IEEE Trans. on Knowledge and Data Engineering, 5(4), 629-643. Shah, P. and J. Wong (1994) Transaction management in an object-oriented data base system. Journal of Systems Software, 115-124. Valduriez, P. (1987) Join Indices. ACM Trans. on Database Systems, 12 (2), 218-246. Woelk, D., W. Kim, and W. Luther (1986) An object-oriented approach to multimedia databases. Proc. of ACM SIGMOD, Washington, DC, U.S.A. Woelk, D. (1987) Multimedia information management in an object-oriented database system. Proc. of the 13th VLDB Conference, Baltimore, MD. U.S.A.