- Email: [email protected]
Linkage versus integration for binding database and interactive graphics systems
Inform. .SysremsVol. 12, No. 3, pp. 271-280, 1987 Great Britain
0306-4379/87 S3.00 + 0.00 Pergamon Journals Ltd
Printed in
LINKAGE VERSUS INTEGRATION FOR BINDING DATABASE AND INTERACTIVE GRAPHICS SYSTEMS M.
ZAKI
and R. SALAMA
Cairo, Egypt (Received 9 June 1986; in revised form 15 December
1986)
Abstract-This paper provides a novel technique for binding database and interactive graphics systems in small computing systems. Such a technique is investigated and compared with other binding methods in order to indicate the essential differences and the corresponding trade-offs. Actually, the binding method that has been implemented in various works is the integration of two systems through a specially-designed interface. Firstly, this approach has been explored and its essential features are explained. Hence our proposed method is presented. It depends on establishing a linkage between the two underlying systems using the file management module of the host operating system. Accordingly, the entire control flow is included in a batch file. This paper emphasizes the details of the linkage technique including the linkage mechanism, the manipulation of both graphical and nongraphical data and the role of the operating system file manager. In addition, a case study concerning a stock-control example has been carried out to confirm the applicability of the linkage approach. The case study represents an implementation of the linkage method for binding a relational database system and a computer-aided-design graphics package. Accordingly, various operational conditions have been examined including multilevel graphical structures. Key words: Integration, pictorial database, linkage technique, file management, batch file, command file, data structure, graphical meaning, data syntax, data semantics, relational data model.
1. INTRODUCTION Many modern computer applications have stimulated the need for pictorial database systems [ 1,2]. In these applications the database and graphics processing systems are collected together to provide the needed facility. On the basis of the hierarchical viewpoint of the system software [3], intuitively, there will be three approaches for gathering the two systems together. As shown in Fig. 1, these approaches are:
(1) The integration of the two systems. In this case (Fig. la) the underlying systems are located in the same level and integrated by using a higher-level interface [4, 51. Thus, such an interface will employ both the database and the graphics systems to accomplish the user (application program) requirements. (2) The combination of the two systems in one software package (Fig. lb). Accordingly the database, graphics and other systems, if any, are combined together to provide an all-in-one package [6]. In this case the combination may be achieved either directly, or indirectly (via local interfaces) at the same level of the two packages. (3) The linkage of the underlying systems. In this case (Fig. lc) database and the graphics systems are linked through a lower-level module, namely, the file manager of the host operating system. Effectively, in this case, the traditional techniques for linking system programs are adapted and relied upon to provide the required binder in which the entire control flow is accomplished by means of a batch file.
Most previous works have used the integration as a vehicle for implementation where the high-level interface may be designed using the characteristics of the database and the graphics systems only. Other details of lower-level software systems may not be needed for the design and the construction of the interface. Also, some available packages are based on the second approach which combines both the database and the graphics systems in one software unit. Here, the combination approach (all in one) will not be considered because it combines some database features with some graphics features (as well as other features, if necessary) in a dedicated package for particular applications. Naturally, in the resultant package, various database and graphics capabilities are sacrificed. The decision, whether a capability may be sacrificed or not, is critical. It depends essentially on the application objectives which are beyond the scope of this work. A comparison of the integration and the linkage approaches indicates that the integration may be used on large computers with the advantages of flexibility and function-varsatility. On the other hand, the linkage approach has the property that one system is acting at a time, as will be explained in Section III. Therefore, that approach is more convenient for small computers. Section II presents the integration technique as a traditional binding approach, while the details of the linkage approach are introduced in Section III. Hence, to confirm the applicability of the latter approach, a linkage method is implemented for bind271
212
M.
ZAKI
and R.
SALAMA
(b)
Fig. 1. Binding approaches. (a) Integration approach. (b) Combination approach. (c) Linkage approach. ing a relational database system and a computeraided-design package. Such a case study is included in Section IV. In addition the trade-offs of linkage relative to integration are pointed out.
II. THE INTEGRATION
APPROACH
This approach will be investigated, without loss of generality, on the assumption that the implemented database system exploits a relational model [7-91. Thus, the graphical and nongraphical data might be handled in a uniform way throughout the system. This capability is made possible by allowing the “syntax” and the “semantics” of the underlying data to be stored in the database [4, lo]. To support both the relational database and the graphics systems a higher-level interface is necessary. Such a global interface includes three modules (interfaces). Namely, these interfaces are: the database interface, the graphics interface and the user interface (Fig. 2). II. 1. Database interface The relational database system is used, generally, for storing nongraphical data. Even when graphical data is stored in the database, it is not directly available for input/output processing. Thus, the relational model concepts should be. extended in order to be capable for supporting pictorial database [l l-141.
11.2. Graphics interface The graphics interface [4, 1l] is responsible for providing the usual commands to draw lines, text,
solid areas and raster data. Such an interface (Fig. 2) is associated with: (1) a data interpreter, (2) a correlation handler. The interpreter scans the data in a relation and creates a picture based on the semantics of that data. It can also handle the hierarchical structure of data. If there is a reference to another name, then the interpreter will draw the named item if it is a relation or execute it if it is a subprogram. As the interpreter creates a logical picture it also generates a correlation table to connect the user actions on the picture with the corresponding data in the database system i.e. the interpreter can map the user actions into database transactions. Correlation is the identification of an item in the database by pointing at its representation on the display. The correlation process involves two steps: (i) identifying the item on the display, (ii) binding the displayed item to the database system. Thus the correlation mechanism is responsible for locating the X, y-coordinates of the underlying position. 11.3. User interface For interactive graphics [lS-17] such an interface is effectively a command language interface that includes the following: (a) a basic set of commands, (b) a textual relations editor,
Binding database and interactive graphics systems
273
USER I
_ INTERPRETER
MANAGEMENT
Fig. 2. An integrated pictorial database system.
(c) a graphical relations editor, (d) a menu building and sequencing facility, (e) a dynamic loading facility. A basic set of commands may include utilities to define, manipulate and display relations as well as tuples. The textual editor allows the user to edit the tabular form of a relation. Thus one can add, delete, or modify the text of a tuple. On the other hand the graphical editor allows the user to edit the graphical form of a relation. Consequently items in the pictorial representation of a relation can be moved, added, deleted or modified.
III. THE LINKAGEAPPROACH This section presents the fundamental concepts and the logical relations to bind database and graphics systems by linking them through the file managemeut module of the host operating system (Fig. 3). However, the implementation details for constructing a pictorial database system are given in the next section. Such an approach allows user-interaction through a menu that should fulfill the user needs. As shown in Fig. 3, there are two alternatives to carry out the process of linkage. In the first alternative the menus is applied directly on the database management system which will be responsible for creating and manipulating all programs that correspond to the menu options, (Fig. 3a). Thus the binding-
direction is “from” the database system which acts as a master “to” the graphics system which acts as a slave. The second alternative represents a binding in a reverse direction i.e. “from” the graphics system “to” the database system (Fig. 3b). Regardless of the binding direction, the linkage process may be investigated as follows. III. 1. Function invocation
Here function invocation is accomplished by displaying a function menu of light buttons on the screen from which the desired function can be indicated with a pick device [18]. Such a menu is composed of a list that represents the available functions. A typical menu [19] may include: -create a database, -add records to the database, -delete records from the database, -update some records from the database. -retrieve data, -insert record, -add symbol to the picture, -delete symbol from the picture, -update the picture, -change the current window, -exit (go to the host operating system). In this case a unique button is assigned to each one of the above functions. When a button is chosen, then the corresponding program that performs the func-
274
M. ZAKIand R. SALAMA (a)
(b)
w
w
USER
USER
t DATABASE MANAGEMENT SYSTEM
GRAPHICS SYSTEM 8
-
OPERATING SYSTEM FILE MANAGER
DATABASE MANAGEMENT SYSTEM 1
-
-
OPERATING SYSTEM FILE MANAGER
-
1 BATCH FILE t COMMAND FILE b INPUT FILE
Fig. 3. A linked pictorial database system. (a) From database to graphics. (b) From graphics to database.
tion will be activated. The interaction
between a user and the pictorial database system is adequately understood as an event menu-driven process in which the events correspond only to user-actions. Thus, the system responds appropriately to an event and then waits for the next event to occur. The following algorithm represents a scheme for a typical interactive application to invoke a function by making use of a menu.
In this scheme, the WAIT-PICK procedure will either time out or return, as data, the button-number that has been picked by the user. 111.2. Linkage mechanism An important feature, without which the linkage process would be impossible, is that the host operating system should have the capability of mapping the input stream from an input device into a string
begin
[introduce the required initialization, if any] main-done: = false [the start of the menu-driven loop] repeat
WAIT-PICK (wait-time, button-number); [A procedure if (button-number > = 0) that makes the system waits and (button-number < = max) for a button to be picked] then [legal button]
of 0:SCREEN-FEEDBACK;
case button-number
[waiting for function selection]
1: action 1; 2: action 2:
(max - 1): action (max - 1); max: main-done: = true end [case) else SCREEN-FEEDBACK until main-done; end
[exit button] [illegal selection, user may try again]
Binding database and interactive graphics systems maintained in a text file. Thus, the database system can create a text file that acts as an input string to the graphics system (Fig. 3a). Similarly, the reverse direction of binding is also available so that the graphics system can create a file provided with the input to the database system (Fig. 3b). As the intermediate file is written by a master system and is read by another system (slave), therefore, it seems that a language processor may be necessary to translate the master output into an identifiable input for the slave system. However, in this situation, if the text file is written as an ASCII (or EBCDIC, if available) code, then it can be mutually used. That file will be responsible for transferring the output of the master system, as an ASCII input, to the slave system. A typical format for that process [20] can be expressed as follows; <[drive name] [path name] file name. This format of the specified facility assigns the standard input sequence to the specified file. Consequently, during the execution of the batch file, the symbol “ < ” is interpreted by the host operating system so that all the inputs to the slave system come from the named input text file instead of from the keyboard (standard input device). The slave system may be either the database or the graphics system according to the direction of binding. For small computer systems where the disk storage (floppy or hard disk) is used, the drive name and path name phrases are used to specify the location of the input file. Here, it should be emphasized that more than one input text file may be included for each menu option that requires the slave system. In such a case, the first input file will contain, in addition to other data, the name of the second input file which contains the name of the third input file and so on. 111.3. Batch Jile The batch file manages the whole system by directing the control to either the database or the graphics system according to the job requirement [21]. So, only one of the two systems will be available at a time by loading it into memory. The contents of the batch file vary according to the binding direction but its role does not. In general, the batch file contains operating system commands to carry out the following sequences: Step
1:
Step
2:
Step
3:
Step
4:
ask the user to make the master system ready to be loaded into the main memory. start execution of the master system program. start execution of the main menu program which allows the selection of a menu option. execute the program corresponding to the user selected option.
Step
5:
Step
6:
Step
7:
Step
8:
Step
9:
Step 10:
215
repeat steps 3 and 4 until the user selects the option corresponding to “exit to operating system”. check whether the reversed file name corresponding to the first input file, is found or not. If it is not created, then execute step 10 directly. Otherwise, execute in the normal sequence i.e. step 7-step 10. ask the user to make the slave system ready for loading into memory instead of the master system. execute the slave system by using the redirection facility. delete any file with a name like the first, input text file. ask the user if he or she wants to repeat the whole job again or not. If the answer is yes, then go to execute step 1, else terminates batch file job.
111.4. Pictorial database processing For convenience, two operational cases will be considered separately. These two cases are: (i) the binding direction is from the database to the graphics system, (ii) the direction is reversed to be from the graphics to the database system. In both cases a relational database model is assumed. 111.41. From database to graphics. In this case, the database system receives the user actions and it will be responsible for managing both textual and graphical data. To facilitate the linkage process, the database system uses the following files. (1) The command file (Fig. 3a), that contains a sequence of data processing commands. (2) The text file(s) that can hold the data being processed. Typical pictorial database applications may include insertion, deletion, modifying and repositioning of an object. Here the insertion operation is given in detail, however, other operations can be similarly understood. The insertion program that corresponds to the insertion option of the menu consists of five command files. These files are carried out sequentially so that the last file is executed if, and only if, the first three files are finished successfully, otherwise an error message would be indicated. The role of these files is pointed out in the following: (1) The first command file is to check whether the requested database has been created before or not. (2) The second command file is to check whether the requested database contains records in it or it is empty. (3) The third command file is to check that the inserted record belongs to the requested database.
M. ZAKI
276
and R. SALAMA
(4) The fourth command file is to handle the insertion operation itself by exploring the built-in insert command of the used database system. It also checks whether the inserted record references any other database(s) or not. If any references are involved then it creates such databases if they are not created before. (5) The last command file is to direct the control of the program to the main menu program without creating any input text files. Other graphical operations which apply to whole relations such as windowing, screen clearing and reading locators can be treated as global parameters. Thus, they can be handled as commands (involved in a command file) to set modes for the display controller. The actual parameter values can be located either in separate domains within the system relations or even in separate relations. 1114.2. From graphics to database. In this case the graphics system receives the menu options chosen by the user (Fig. 3b), and exploits the database system to accomplish the object modelling. Thus the database system is used to store all the graphical and nongraphical data, including the object hierarchy, and to construct the traverser by using usual database queries. Here, queries can be formatted to receive the tuples of relations which are similar to linked lists in traditional picture modelling. In the relational database, only logical pictures are stored. A logical picture is defined as the hierarchically structured collection of picture objects. The logical picture can thus be stored using a number of usual relations. The address of each relation is not stored in the relation itself, however, the database system is responsible for mapping the symbolic name of a relation to its actual (physical) location. To make the above ideas clear, consider the simple picture shown in Fig. 4. To define a corresponding logical picture, two relations are used. (1) The Picture Object Relation (Table 1). In this relation each object, essentially has a unique name, a labelling position (xi, n) and the transformation parameter that specifies a scale, relation, or etc. However, in a real application many other domains can be added to Table 1.
Fr-ci I
I:‘! 1
Picture
D
Fig. 4. A sketch of a logical picture.
Table 1. The logical OBJNAME A B
C
OWNNAME
picture D
Xrel
Yrel
0 4
4 4 1
D D D
I
TRANSF. Tl T2 T3
(2) The Picture Contour Relation. Every labelled object in the above relation, will have a contour stored in the picture contour relation. The contours of objects A, B and C are given in Table 2. In this case, the file name for the physical picture object is given in the domain FNAME. The contours of A, B and C are expressed as sequences of ASCII code line segments. Thus, the contour codes for a given picture object can be retrieved using the object name as a key. By making use of these two relations, the picture of Fig. 4 can be easily manipulated (stored, retrieved, modified or deleted) since each elementary object will be processed as a normal tuple in a relation. 111.5. Discussion and comparison of linkage and integration approaches In the following, the basic features and the operational requirements for using a pictorial database system (either integrated or linked) are pointed out. Also a comparison of the linkage and integration approaches is included (items 3, 4 and 5). (1) The binding process facilitates many functions to be easily invoked. Consequently, a user may directly obtain information that was difficultly afforded without a pictorial database system. On the other hand, the use of two general-purpose packages, instead of a tailored software system, is expensive and represents additional overheads on the system resources. Also, in this case the execution efficiently may be reduced. (2) In a pictorial database system, the manipulation of data is carried out homogenously, in the sense that both graphical and nongraphical data are represented by the model relations. (3) A comparison of the integration and linkage approaches indicates that the integration is more flexible and powerful because of the versatility of the functions of the high-level interface. (4) The linkage technique through the host operating system provides a cost-effective approach, however, the host operating system should afford the facilities which make the linkage possible (see Section III). (5) The linkage approach has the property that one system acts as a master while the other acts as a Table 2. Contours ELEMNAME A
of obiects A. B and C
Mode
FNAME
Visible
P.A.
Contour
codes
(6.WW.2).W)l KW, W)l WL%(‘Wl W,2),
B
Visible
P.B.
W93).(5,3)1K593).(5,7)1 [(5.7),(t,7)1[(t,7).(1.3)1
C
Visible
P.C.
U2,4), (4,411 K4.41, (4,611 1f4.6). (2.6jlrt2.6). (2.4)1
Binding database and interactive graphics systems slave, depending on the direction of binding. Actually, one system is acting at a time. Therefore, it is more convenient for small computing systems. The following features may be suggested to facilitate the linkage process. (i) The operating system redirection feature may permit a mixed input from both the keyboard and the input text file. (ii) The batch file may be supported by a lot of features that make it act effectively as a shell processor. Such features may include: (a) full screen editing capabilities to set up screen format, (b) the use of variables within it, and (c) high looping technique. By these features, we can create a main menu-driven linking which contains the two possibilities for binding the database system and the graphics system. (iii) Software systems may include commands such as: (a) A command capable of terminating program execution and then start execution of operating system utilities or other software programs. So it may execute the redirection feature directly from this command. (b) A command capable of creating a text file which can contain output data, extracted data, direct data and other data without any disturbance to the command file which uses this command. (c) A command capable of supporting the suggested redirection feature stated before.
217
Table 4. The shipment
otv
Sl s2 s3
PI P2 Pl
300 400 200
Table 5. ELEMENT ELEMNAME NUT
XTRANS
This configuration is employed to perform the traditional stock-control application of reference [24]. The relations of that application are given in Tables 3-8. Table 3 represents the stored parts. Thus, it contains for each stored part, the part number, name, a labelling position at which the nongraphics data is displayed, weight, location where the part is stored, and a reference to an ELEMENT relation. Table 4 Table 3. The part relation PNO
PNAME
Xrel
Yrel
PI P2 P3 P4
NUT SCREW BOLT CAM
1 1
8 8 8 8
I 1
Weight 12 17 17 14
P City
London Parts Rome London
Shape ELEMENTI ELEMENT2 ELEMENT3 ELEMENT4
YTRANS 4
contains for each shipment, the supplier number, the corresponding part number, and the quantity shipped. Tables 5 and 6 are examples of the ELEMENT relations where each one contains, for each graphical element occurrence, the element name and translational position to that part. The occurrences of the ELEMNAME domain, point to reference relations which contain the current X- and Y-values, for each line that defines the element. Tables 7 and 8 are examples of such relations. In this case study, the linkage has been carried out in two directions i.e. from the graphics to the database system and from the database to the graphics system. Actually, the binding mechanism is the same regardless of the linkage direction. If the AutoCAD acts as a master for which the object representation is accomplished using the relational data model of
SCREW NUT
Compuging System: WANG Professional Computer Operating System: MS-DOS [20] Database System: DBASE II [22] Graphics System: AutoCAD [23].
1 relation
5
Table 6. ELEMENT
Actually, many pictorial database systems are implemented by “integrating” both the database and graphics systems. However, this case study presents a prototype that has been built by “linking” both systems (instead of integrating them). The basic features of this work are listed in the following:
SP
PNO
ELEMNAME IV. CASE STUDY
relation
SNO
XTRANS
2 relation YTRANS
0 2.5
Table 7. NUT
0 2.5
relation
XPOS
YPOS
5 6 6 5 5 5.4 5.4 5.6 56
5 5 4.5 4.5 5 5 4.5 4.6 5
Table 8. SCREW
relation
XFQS
YPOS
2 3 2.8 2.2 2 2.2 2.2 2.8 2.3 2.3 2.5 2.7 2.7
4 4 3.6 3.6 4 3.6 3.2 3.2 3.2 1.6 1.4 1.6 3.2
278
M.
ZAKI
and R.
DBASE II, then, such application will be similar to that given in reference [19]. Therefore, here we consider only the linkage technique when the binding direction is from DBASE II to AutoCAD. The details of the linkage process are explained in the Appendix using two illustrative queries, one for insertion and the other for retrieval. These queries are: (1) Add a new part to Table 3 from a supplier who is already existing in Table 4. (2) Retrieving the shapes of all the parts that satisfy a particular condition. The first query needs an ADDing program, Appendix (l), that consists of three command files. The first file searches the SP relation for a record satisfying the entered part number. If such record is not found it allows the user to add the new record. The second command file creates a relation that corresponds to the inserted part. Such a relation will have the same name as the content of the record SHAPE field. Eventually, the third command file returns control to the system menu without creating any input files. The second query needs four command files, Appendix 1. The first file checks whether the requested record is actually existing. If it is not found, then control is returned to the system menu. The second command file extracts the nongraphical data of the fetched record. The third and fourth files are responsible of passing all the attributes associated with the fetched record to the slave package as normal AutoCAD commands and displaying the shapes of all retrieved parts, respectively. V. CONCLUSION
A novel technique has been presented to bind database and interactive graphics systems for constructing a pictorial database system. Such a technique is based on the traditional approach for linking software products. For that approach, the logical concepts, the system hierarchy and the implementation details are given. The linkage mechanism is investigated in order to emphasize: (1) the role of the database system, (2) the role of the graphics system and (3) the role of the operating system. In addition, the attributes manipulation and the sequence used for passing parameters from one system to another is given. This work has indicated two directions of linkage, the first concerns a binding from the graphics to the database system and the second represents a binding in the opposite direction. By comparing the linkage approach with other binding approaches, it can be fairly concluded that the linkage is quite reasonable for small computers because of the following advantages: (a) straightforward implementation, (b) no need for a global interface, (c) economical storage size is required since only one system exists in the main memory at a time.
SALAMA
Eventually, the implementation of the proposed technique on a small computing system has confirmed its applicability as well as it has exposed the basic requirement needed in order to facilitate the linking mechanism. REFERENCES
[l] S. K. Chang and T. L. Kunii. Pictorial data-base systems. IEEE Comput., pp. 1321 (November, 1981).
[2] F. A. Brings et al. PUMPS architecture for oattern analysis anh-image database management. IEEE Trans. Comput. C-31(10), 969-983 (October, 1982). [3] S. E. Madnick and J. J. Donvan. Operating Systems. McGraw-Hill, New York (1974). [4] F. Palermo and D. Weller. Picture building system. IBM Research Rept RJ2436, San Jose, Calif. (January, 1979). [5] K. Hwang and K. S. Fu. Integrated computer architecture for image processing and database management. IEEE Comput., p. 51-60 (January, 1983). [6] Lorus l-2-3 User’s Manual. Lotus Development Corp., Cambridge (1983). [7] S. K. Chang, N. Donoto, B. H. McCormick, J. Reuss and R. Rocchetti. A relational database system for pictures. Dept of Information Engineering, Illinois University of Chicago Circle (1977). [8] N. S. Chang and K. S. Fu. A relational database system for images. Rent TR-EE 79-28. Deot of Electrical Engineehng, P&due University (May: 1979). [9] R. Williams. On the application of relational data structures in computer graphics. IFIP Conf. Proc. (1974).
WI D. W. Weller and F. P. Palermo. Database require-
ments for graphics. IBM research rept RJ2435, San Jose, Calif. (January, 1979). Pll R. A. Lorie, R. Casajuana and J. L. Becerril. GSYSR: relational database interface for graphics. IBM Research Reot RJ2511. San Jose. Calif. (April. 1979). WI W. G. Moorhead. GXRAM: relationaldatabase interface for graphics. IBM Research Rept RJ1735, San Jose, Calif. (1976). [I31 R. Williams and G. M. Giddings. A picture building system. IEEE Trans. Sofrware Engng SE-2(l), 6266 (March, 1976). 1141D. M. McKeown Jr and D. Raj. Reddy. A hierarchical symbolic representation for an image database. Proc. IEEE Workshop on Picture Dora Description and Man agemenr, pp. 4@44 (April, 1977). [I51 G. Enderle, K. Kansy and G. Pfaff. Computer Graphics Programming. Springer Verlag, Berlin (1984). iI61 W. M. Newmann and R. F. Sproull. Principles of Interactive Computer Graphics. McGraw-Hill, New
York (1982). 1171N. S. Chang and K. S. Fu. Picture query language for pictorial ,__ . data-base _^^_. system. IEEE Compur., pp. 2330 (November, IYII). [18] T. L. Kunii, T. Amano, H. Arisawa and S. Okada. An interactive fashion-design System; INFADS. Compur. Graphics l(4), 297-302 (1980). [19] J. D. Foley and A. Van Dam. Fundamentals of Inreractive Computer Graphics. Addison-Wesley, Reading,
Mass. (1982). [20] WANG Professional Cornpurer User Manual for Disk Operating System. Wang Lab., Mass. (December, 1983). [21] Adi J. Khambata. Microprocessor/Microcomputer Architecture Software and Svsrem. Wilev. _ New York (1982). ” [22] DBASE II User Manual. Ashton-Tate, Calif. (1981). [23] AuroCAD User Manual. Autodesk Inc., San Jose, Calif. (1984).
Binding database and interactive graphics systems (241 C. J. Date. An Introduction to Dambase Systems. Addison-Wesley, Reading, Mass. (1977). APPENDIX The Procedural Operations for Linkage from DBASE II to AutoCAD Two illustrative queries are considered: (1) Adding a new part to Table 3 from a supplier who is already existing in table 4.
This query needs programming of three command files: I. The first command file will: 1. Accept a supplier number and a part number from the user. 2. Search the SP relation to find out the record that satisfies the entered supplier number. 3. If such a record is not found, then the program is terminated. Otherwise, the P relation is searched for a record satisfying the entered part number. 4. If such a record is found in the P relation, then the program is terminated since this new part is already defined. Otherwise, the system allows the user to enter the contents of the fields of the new record, and then appends the new record to the P relation. II. The second command file will: 1. Search for a relation whose name is the same as the content of the SHAPE field of the new record. 2. If such a relation is found, then the ADDing program is terminated since the drawing shape of the new added part is already defined. Otherwise, a new relation, with the same structure as any ELEMENT relation, is created where its name is the same as the content of the SHAPE field of the added record. 3. Allow record(s) insertion into the created relation, so that for each entered record, the following steps are repeated until the end of the relation. 3(a) Check whether a relation with the same name as the content of the ELEMNAME field is already created or not. 3(b) If such a relation is not found, then a new relation having a name as the content of the ELEMNAME field is created. Then, the records of that relation which represent the logical picture are inserted. 3(c) Go to the next record of the named ELEMENT relation. III. The last command file is to return the control to the main menu without creating any input tiles. (2) Retrieving the shapes of all the parts that satisfy a certain condition (e.g. part(s) supplied by a supplier whose SNO = Sl). In this case, the input text files are created by the DBASE II command “SET ALTERNATE TO (filename)” which creates a file for saving the text edited on the screen. A new data can be appended to that file by the DBASE II command “SET CONSOL ON” [22]. For each retrieved part, an input file is created to hold the graphical element(s) of that part, One more input file which does not contain any graphical data, will be created at first. This input contains the data elements required to start up the AutoCAD program. Such data elements are: (1) drive name at which the AutoCAD overlay files can be found; (2) AutoCAD menu option number corresponding to begin new drawing; (3) a pseudo-drawing file name; (4) SCRIPT (filename) which is the name of the second input file which holds the graphical element(s) of the first retrieved part. Each subsequently created input file will correspond to a retrieved part and it contains, at its end, the name of the
279
next input file. The last input file will contain, at its end, instead of the next file name, the number of AutoCAD menu option corresponding to EXIT AutoCAD. The AutoCAD will accept its input from the first input file which will chain the other input file(s). The AutoCAD treats the chained input file(s) as SCRIPT field which is an AutoCAD feature [23]. So, the batch file must change the extension names of such files to be SCR instead of .TXT. The retrieval program which has been used to answer this query, consists of the following four command files. I. The first command file must: 1. Accept two entitites from the user; a relation name and a search condition. 2. Check whether the requested relation is the SP or P. If it is neither SP nor P, it should indicate an error message. Otherwise, if the requested relation is the SP, then it will be searched for a record satisfying the entered search condition 3. If such a record is not found, then the system indicates that there is no record satisfying this condition and returns the control to the main menu without creating any input files. Otherwise, make the given search condition be the content of the PNO field of the fetched record. II. The second command file will: 1. Search, the P relation, for a record satisfying the search condition (entered or modified). 2. Once such record is found, the first input file is created as discussed before. 3. Extract the nongraphical data of the fetched record. The contents of the PNAME, WEIGHT, and CITY fields, are the nongraphics data. III. The third command file will: 1. Search for a relation having the same name as the content of the SHAPE field of the fetched record. 2. Once such a relation is found, create an input file whose name is listed in the first created input tile. 3. Store the extracted nongraphics data in that file but in a form suitable to be executed by the AutoCAD TEXT command. 4. For each record found in the corresponding ELEMENT relation, the following operations are repeated until the end of that relation: (a) Search for a relation having a name as the content of the ELEMNAME field. (b) once such relation is found, translates all the occurrences of its XPOS and YPOS fields by the XTRANS and YTRANS fields of the used ELEMENT relation. The translated points are Xnew = XPOS + XTRANS and Ynew = YPOS + YTRANS. (c) Append the translated points to the used input file. They must be in a suitable form so that they can be. accepted as an AutoCAD LINE command. (d) Append also the AutoCAD command DELAY 1000, to delay the execution of the next command to AutoCAD. If the end of the corresponding ELEMENT relations is reached, then append to the used input file, the AutoCAD command QUIT Y. VI. The last command file must: 1. Check whether the relation requested before, has more records satisfying the entered search condition or not. 2. If none found, then the previous created input file will be the last input file. Accordingly, it is appended by the AutoCAD menu option number corresponding to EXIT AutoCAD and the control is returned to the operating system. 3. Otherwise, the following steps should be repeated until no more records satisfying the search condition (modified or not) are found.
M.
280
ZAKI
and R.
3(a) Append to the preceding input file the AutoCAD menu option numner which corresponds to begin new drawina. the content of the SHAPE field of the fetched record and eventually the next input file name. 3(b) Extract the nongraphical data that corresponds to the processed record. 3(c) Create an input file to maintain the extracted nongraphical data. II
SALAMA
3(d) Search for a relation that has the same name as the content of the SHAPE field of the fetched record. 3(e) For each record found in the corresnondina ELEMENT. relation, get the ELEMNAME td identrfy the relations that describe the required object. 3(f) After making the necessary translation, store in the input file the X- and Y-attributes of the required objects.
0306-4379/87 S3.00 + 0.00 Pergamon Journals Ltd
Printed in
LINKAGE VERSUS INTEGRATION FOR BINDING DATABASE AND INTERACTIVE GRAPHICS SYSTEMS M.
ZAKI
and R. SALAMA
Cairo, Egypt (Received 9 June 1986; in revised form 15 December
1986)
Abstract-This paper provides a novel technique for binding database and interactive graphics systems in small computing systems. Such a technique is investigated and compared with other binding methods in order to indicate the essential differences and the corresponding trade-offs. Actually, the binding method that has been implemented in various works is the integration of two systems through a specially-designed interface. Firstly, this approach has been explored and its essential features are explained. Hence our proposed method is presented. It depends on establishing a linkage between the two underlying systems using the file management module of the host operating system. Accordingly, the entire control flow is included in a batch file. This paper emphasizes the details of the linkage technique including the linkage mechanism, the manipulation of both graphical and nongraphical data and the role of the operating system file manager. In addition, a case study concerning a stock-control example has been carried out to confirm the applicability of the linkage approach. The case study represents an implementation of the linkage method for binding a relational database system and a computer-aided-design graphics package. Accordingly, various operational conditions have been examined including multilevel graphical structures. Key words: Integration, pictorial database, linkage technique, file management, batch file, command file, data structure, graphical meaning, data syntax, data semantics, relational data model.
1. INTRODUCTION Many modern computer applications have stimulated the need for pictorial database systems [ 1,2]. In these applications the database and graphics processing systems are collected together to provide the needed facility. On the basis of the hierarchical viewpoint of the system software [3], intuitively, there will be three approaches for gathering the two systems together. As shown in Fig. 1, these approaches are:
(1) The integration of the two systems. In this case (Fig. la) the underlying systems are located in the same level and integrated by using a higher-level interface [4, 51. Thus, such an interface will employ both the database and the graphics systems to accomplish the user (application program) requirements. (2) The combination of the two systems in one software package (Fig. lb). Accordingly the database, graphics and other systems, if any, are combined together to provide an all-in-one package [6]. In this case the combination may be achieved either directly, or indirectly (via local interfaces) at the same level of the two packages. (3) The linkage of the underlying systems. In this case (Fig. lc) database and the graphics systems are linked through a lower-level module, namely, the file manager of the host operating system. Effectively, in this case, the traditional techniques for linking system programs are adapted and relied upon to provide the required binder in which the entire control flow is accomplished by means of a batch file.
Most previous works have used the integration as a vehicle for implementation where the high-level interface may be designed using the characteristics of the database and the graphics systems only. Other details of lower-level software systems may not be needed for the design and the construction of the interface. Also, some available packages are based on the second approach which combines both the database and the graphics systems in one software unit. Here, the combination approach (all in one) will not be considered because it combines some database features with some graphics features (as well as other features, if necessary) in a dedicated package for particular applications. Naturally, in the resultant package, various database and graphics capabilities are sacrificed. The decision, whether a capability may be sacrificed or not, is critical. It depends essentially on the application objectives which are beyond the scope of this work. A comparison of the integration and the linkage approaches indicates that the integration may be used on large computers with the advantages of flexibility and function-varsatility. On the other hand, the linkage approach has the property that one system is acting at a time, as will be explained in Section III. Therefore, that approach is more convenient for small computers. Section II presents the integration technique as a traditional binding approach, while the details of the linkage approach are introduced in Section III. Hence, to confirm the applicability of the latter approach, a linkage method is implemented for bind271
212
M.
ZAKI
and R.
SALAMA
(b)
Fig. 1. Binding approaches. (a) Integration approach. (b) Combination approach. (c) Linkage approach. ing a relational database system and a computeraided-design package. Such a case study is included in Section IV. In addition the trade-offs of linkage relative to integration are pointed out.
II. THE INTEGRATION
APPROACH
This approach will be investigated, without loss of generality, on the assumption that the implemented database system exploits a relational model [7-91. Thus, the graphical and nongraphical data might be handled in a uniform way throughout the system. This capability is made possible by allowing the “syntax” and the “semantics” of the underlying data to be stored in the database [4, lo]. To support both the relational database and the graphics systems a higher-level interface is necessary. Such a global interface includes three modules (interfaces). Namely, these interfaces are: the database interface, the graphics interface and the user interface (Fig. 2). II. 1. Database interface The relational database system is used, generally, for storing nongraphical data. Even when graphical data is stored in the database, it is not directly available for input/output processing. Thus, the relational model concepts should be. extended in order to be capable for supporting pictorial database [l l-141.
11.2. Graphics interface The graphics interface [4, 1l] is responsible for providing the usual commands to draw lines, text,
solid areas and raster data. Such an interface (Fig. 2) is associated with: (1) a data interpreter, (2) a correlation handler. The interpreter scans the data in a relation and creates a picture based on the semantics of that data. It can also handle the hierarchical structure of data. If there is a reference to another name, then the interpreter will draw the named item if it is a relation or execute it if it is a subprogram. As the interpreter creates a logical picture it also generates a correlation table to connect the user actions on the picture with the corresponding data in the database system i.e. the interpreter can map the user actions into database transactions. Correlation is the identification of an item in the database by pointing at its representation on the display. The correlation process involves two steps: (i) identifying the item on the display, (ii) binding the displayed item to the database system. Thus the correlation mechanism is responsible for locating the X, y-coordinates of the underlying position. 11.3. User interface For interactive graphics [lS-17] such an interface is effectively a command language interface that includes the following: (a) a basic set of commands, (b) a textual relations editor,
Binding database and interactive graphics systems
273
USER I
_ INTERPRETER
MANAGEMENT
Fig. 2. An integrated pictorial database system.
(c) a graphical relations editor, (d) a menu building and sequencing facility, (e) a dynamic loading facility. A basic set of commands may include utilities to define, manipulate and display relations as well as tuples. The textual editor allows the user to edit the tabular form of a relation. Thus one can add, delete, or modify the text of a tuple. On the other hand the graphical editor allows the user to edit the graphical form of a relation. Consequently items in the pictorial representation of a relation can be moved, added, deleted or modified.
III. THE LINKAGEAPPROACH This section presents the fundamental concepts and the logical relations to bind database and graphics systems by linking them through the file managemeut module of the host operating system (Fig. 3). However, the implementation details for constructing a pictorial database system are given in the next section. Such an approach allows user-interaction through a menu that should fulfill the user needs. As shown in Fig. 3, there are two alternatives to carry out the process of linkage. In the first alternative the menus is applied directly on the database management system which will be responsible for creating and manipulating all programs that correspond to the menu options, (Fig. 3a). Thus the binding-
direction is “from” the database system which acts as a master “to” the graphics system which acts as a slave. The second alternative represents a binding in a reverse direction i.e. “from” the graphics system “to” the database system (Fig. 3b). Regardless of the binding direction, the linkage process may be investigated as follows. III. 1. Function invocation
Here function invocation is accomplished by displaying a function menu of light buttons on the screen from which the desired function can be indicated with a pick device [18]. Such a menu is composed of a list that represents the available functions. A typical menu [19] may include: -create a database, -add records to the database, -delete records from the database, -update some records from the database. -retrieve data, -insert record, -add symbol to the picture, -delete symbol from the picture, -update the picture, -change the current window, -exit (go to the host operating system). In this case a unique button is assigned to each one of the above functions. When a button is chosen, then the corresponding program that performs the func-
274
M. ZAKIand R. SALAMA (a)
(b)
w
w
USER
USER
t DATABASE MANAGEMENT SYSTEM
GRAPHICS SYSTEM 8
-
OPERATING SYSTEM FILE MANAGER
DATABASE MANAGEMENT SYSTEM 1
-
-
OPERATING SYSTEM FILE MANAGER
-
1 BATCH FILE t COMMAND FILE b INPUT FILE
Fig. 3. A linked pictorial database system. (a) From database to graphics. (b) From graphics to database.
tion will be activated. The interaction
between a user and the pictorial database system is adequately understood as an event menu-driven process in which the events correspond only to user-actions. Thus, the system responds appropriately to an event and then waits for the next event to occur. The following algorithm represents a scheme for a typical interactive application to invoke a function by making use of a menu.
In this scheme, the WAIT-PICK procedure will either time out or return, as data, the button-number that has been picked by the user. 111.2. Linkage mechanism An important feature, without which the linkage process would be impossible, is that the host operating system should have the capability of mapping the input stream from an input device into a string
begin
[introduce the required initialization, if any] main-done: = false [the start of the menu-driven loop] repeat
WAIT-PICK (wait-time, button-number); [A procedure if (button-number > = 0) that makes the system waits and (button-number < = max) for a button to be picked] then [legal button]
of 0:SCREEN-FEEDBACK;
case button-number
[waiting for function selection]
1: action 1; 2: action 2:
(max - 1): action (max - 1); max: main-done: = true end [case) else SCREEN-FEEDBACK until main-done; end
[exit button] [illegal selection, user may try again]
Binding database and interactive graphics systems maintained in a text file. Thus, the database system can create a text file that acts as an input string to the graphics system (Fig. 3a). Similarly, the reverse direction of binding is also available so that the graphics system can create a file provided with the input to the database system (Fig. 3b). As the intermediate file is written by a master system and is read by another system (slave), therefore, it seems that a language processor may be necessary to translate the master output into an identifiable input for the slave system. However, in this situation, if the text file is written as an ASCII (or EBCDIC, if available) code, then it can be mutually used. That file will be responsible for transferring the output of the master system, as an ASCII input, to the slave system. A typical format for that process [20] can be expressed as follows; <[drive name] [path name] file name. This format of the specified facility assigns the standard input sequence to the specified file. Consequently, during the execution of the batch file, the symbol “ < ” is interpreted by the host operating system so that all the inputs to the slave system come from the named input text file instead of from the keyboard (standard input device). The slave system may be either the database or the graphics system according to the direction of binding. For small computer systems where the disk storage (floppy or hard disk) is used, the drive name and path name phrases are used to specify the location of the input file. Here, it should be emphasized that more than one input text file may be included for each menu option that requires the slave system. In such a case, the first input file will contain, in addition to other data, the name of the second input file which contains the name of the third input file and so on. 111.3. Batch Jile The batch file manages the whole system by directing the control to either the database or the graphics system according to the job requirement [21]. So, only one of the two systems will be available at a time by loading it into memory. The contents of the batch file vary according to the binding direction but its role does not. In general, the batch file contains operating system commands to carry out the following sequences: Step
1:
Step
2:
Step
3:
Step
4:
ask the user to make the master system ready to be loaded into the main memory. start execution of the master system program. start execution of the main menu program which allows the selection of a menu option. execute the program corresponding to the user selected option.
Step
5:
Step
6:
Step
7:
Step
8:
Step
9:
Step 10:
215
repeat steps 3 and 4 until the user selects the option corresponding to “exit to operating system”. check whether the reversed file name corresponding to the first input file, is found or not. If it is not created, then execute step 10 directly. Otherwise, execute in the normal sequence i.e. step 7-step 10. ask the user to make the slave system ready for loading into memory instead of the master system. execute the slave system by using the redirection facility. delete any file with a name like the first, input text file. ask the user if he or she wants to repeat the whole job again or not. If the answer is yes, then go to execute step 1, else terminates batch file job.
111.4. Pictorial database processing For convenience, two operational cases will be considered separately. These two cases are: (i) the binding direction is from the database to the graphics system, (ii) the direction is reversed to be from the graphics to the database system. In both cases a relational database model is assumed. 111.41. From database to graphics. In this case, the database system receives the user actions and it will be responsible for managing both textual and graphical data. To facilitate the linkage process, the database system uses the following files. (1) The command file (Fig. 3a), that contains a sequence of data processing commands. (2) The text file(s) that can hold the data being processed. Typical pictorial database applications may include insertion, deletion, modifying and repositioning of an object. Here the insertion operation is given in detail, however, other operations can be similarly understood. The insertion program that corresponds to the insertion option of the menu consists of five command files. These files are carried out sequentially so that the last file is executed if, and only if, the first three files are finished successfully, otherwise an error message would be indicated. The role of these files is pointed out in the following: (1) The first command file is to check whether the requested database has been created before or not. (2) The second command file is to check whether the requested database contains records in it or it is empty. (3) The third command file is to check that the inserted record belongs to the requested database.
M. ZAKI
276
and R. SALAMA
(4) The fourth command file is to handle the insertion operation itself by exploring the built-in insert command of the used database system. It also checks whether the inserted record references any other database(s) or not. If any references are involved then it creates such databases if they are not created before. (5) The last command file is to direct the control of the program to the main menu program without creating any input text files. Other graphical operations which apply to whole relations such as windowing, screen clearing and reading locators can be treated as global parameters. Thus, they can be handled as commands (involved in a command file) to set modes for the display controller. The actual parameter values can be located either in separate domains within the system relations or even in separate relations. 1114.2. From graphics to database. In this case the graphics system receives the menu options chosen by the user (Fig. 3b), and exploits the database system to accomplish the object modelling. Thus the database system is used to store all the graphical and nongraphical data, including the object hierarchy, and to construct the traverser by using usual database queries. Here, queries can be formatted to receive the tuples of relations which are similar to linked lists in traditional picture modelling. In the relational database, only logical pictures are stored. A logical picture is defined as the hierarchically structured collection of picture objects. The logical picture can thus be stored using a number of usual relations. The address of each relation is not stored in the relation itself, however, the database system is responsible for mapping the symbolic name of a relation to its actual (physical) location. To make the above ideas clear, consider the simple picture shown in Fig. 4. To define a corresponding logical picture, two relations are used. (1) The Picture Object Relation (Table 1). In this relation each object, essentially has a unique name, a labelling position (xi, n) and the transformation parameter that specifies a scale, relation, or etc. However, in a real application many other domains can be added to Table 1.
Fr-ci I
I:‘! 1
Picture
D
Fig. 4. A sketch of a logical picture.
Table 1. The logical OBJNAME A B
C
OWNNAME
picture D
Xrel
Yrel
0 4
4 4 1
D D D
I
TRANSF. Tl T2 T3
(2) The Picture Contour Relation. Every labelled object in the above relation, will have a contour stored in the picture contour relation. The contours of objects A, B and C are given in Table 2. In this case, the file name for the physical picture object is given in the domain FNAME. The contours of A, B and C are expressed as sequences of ASCII code line segments. Thus, the contour codes for a given picture object can be retrieved using the object name as a key. By making use of these two relations, the picture of Fig. 4 can be easily manipulated (stored, retrieved, modified or deleted) since each elementary object will be processed as a normal tuple in a relation. 111.5. Discussion and comparison of linkage and integration approaches In the following, the basic features and the operational requirements for using a pictorial database system (either integrated or linked) are pointed out. Also a comparison of the linkage and integration approaches is included (items 3, 4 and 5). (1) The binding process facilitates many functions to be easily invoked. Consequently, a user may directly obtain information that was difficultly afforded without a pictorial database system. On the other hand, the use of two general-purpose packages, instead of a tailored software system, is expensive and represents additional overheads on the system resources. Also, in this case the execution efficiently may be reduced. (2) In a pictorial database system, the manipulation of data is carried out homogenously, in the sense that both graphical and nongraphical data are represented by the model relations. (3) A comparison of the integration and linkage approaches indicates that the integration is more flexible and powerful because of the versatility of the functions of the high-level interface. (4) The linkage technique through the host operating system provides a cost-effective approach, however, the host operating system should afford the facilities which make the linkage possible (see Section III). (5) The linkage approach has the property that one system acts as a master while the other acts as a Table 2. Contours ELEMNAME A
of obiects A. B and C
Mode
FNAME
Visible
P.A.
Contour
codes
(6.WW.2).W)l KW, W)l WL%(‘Wl W,2),
B
Visible
P.B.
W93).(5,3)1K593).(5,7)1 [(5.7),(t,7)1[(t,7).(1.3)1
C
Visible
P.C.
U2,4), (4,411 K4.41, (4,611 1f4.6). (2.6jlrt2.6). (2.4)1
Binding database and interactive graphics systems slave, depending on the direction of binding. Actually, one system is acting at a time. Therefore, it is more convenient for small computing systems. The following features may be suggested to facilitate the linkage process. (i) The operating system redirection feature may permit a mixed input from both the keyboard and the input text file. (ii) The batch file may be supported by a lot of features that make it act effectively as a shell processor. Such features may include: (a) full screen editing capabilities to set up screen format, (b) the use of variables within it, and (c) high looping technique. By these features, we can create a main menu-driven linking which contains the two possibilities for binding the database system and the graphics system. (iii) Software systems may include commands such as: (a) A command capable of terminating program execution and then start execution of operating system utilities or other software programs. So it may execute the redirection feature directly from this command. (b) A command capable of creating a text file which can contain output data, extracted data, direct data and other data without any disturbance to the command file which uses this command. (c) A command capable of supporting the suggested redirection feature stated before.
217
Table 4. The shipment
otv
Sl s2 s3
PI P2 Pl
300 400 200
Table 5. ELEMENT ELEMNAME NUT
XTRANS
This configuration is employed to perform the traditional stock-control application of reference [24]. The relations of that application are given in Tables 3-8. Table 3 represents the stored parts. Thus, it contains for each stored part, the part number, name, a labelling position at which the nongraphics data is displayed, weight, location where the part is stored, and a reference to an ELEMENT relation. Table 4 Table 3. The part relation PNO
PNAME
Xrel
Yrel
PI P2 P3 P4
NUT SCREW BOLT CAM
1 1
8 8 8 8
I 1
Weight 12 17 17 14
P City
London Parts Rome London
Shape ELEMENTI ELEMENT2 ELEMENT3 ELEMENT4
YTRANS 4
contains for each shipment, the supplier number, the corresponding part number, and the quantity shipped. Tables 5 and 6 are examples of the ELEMENT relations where each one contains, for each graphical element occurrence, the element name and translational position to that part. The occurrences of the ELEMNAME domain, point to reference relations which contain the current X- and Y-values, for each line that defines the element. Tables 7 and 8 are examples of such relations. In this case study, the linkage has been carried out in two directions i.e. from the graphics to the database system and from the database to the graphics system. Actually, the binding mechanism is the same regardless of the linkage direction. If the AutoCAD acts as a master for which the object representation is accomplished using the relational data model of
SCREW NUT
Compuging System: WANG Professional Computer Operating System: MS-DOS [20] Database System: DBASE II [22] Graphics System: AutoCAD [23].
1 relation
5
Table 6. ELEMENT
Actually, many pictorial database systems are implemented by “integrating” both the database and graphics systems. However, this case study presents a prototype that has been built by “linking” both systems (instead of integrating them). The basic features of this work are listed in the following:
SP
PNO
ELEMNAME IV. CASE STUDY
relation
SNO
XTRANS
2 relation YTRANS
0 2.5
Table 7. NUT
0 2.5
relation
XPOS
YPOS
5 6 6 5 5 5.4 5.4 5.6 56
5 5 4.5 4.5 5 5 4.5 4.6 5
Table 8. SCREW
relation
XFQS
YPOS
2 3 2.8 2.2 2 2.2 2.2 2.8 2.3 2.3 2.5 2.7 2.7
4 4 3.6 3.6 4 3.6 3.2 3.2 3.2 1.6 1.4 1.6 3.2
278
M.
ZAKI
and R.
DBASE II, then, such application will be similar to that given in reference [19]. Therefore, here we consider only the linkage technique when the binding direction is from DBASE II to AutoCAD. The details of the linkage process are explained in the Appendix using two illustrative queries, one for insertion and the other for retrieval. These queries are: (1) Add a new part to Table 3 from a supplier who is already existing in Table 4. (2) Retrieving the shapes of all the parts that satisfy a particular condition. The first query needs an ADDing program, Appendix (l), that consists of three command files. The first file searches the SP relation for a record satisfying the entered part number. If such record is not found it allows the user to add the new record. The second command file creates a relation that corresponds to the inserted part. Such a relation will have the same name as the content of the record SHAPE field. Eventually, the third command file returns control to the system menu without creating any input files. The second query needs four command files, Appendix 1. The first file checks whether the requested record is actually existing. If it is not found, then control is returned to the system menu. The second command file extracts the nongraphical data of the fetched record. The third and fourth files are responsible of passing all the attributes associated with the fetched record to the slave package as normal AutoCAD commands and displaying the shapes of all retrieved parts, respectively. V. CONCLUSION
A novel technique has been presented to bind database and interactive graphics systems for constructing a pictorial database system. Such a technique is based on the traditional approach for linking software products. For that approach, the logical concepts, the system hierarchy and the implementation details are given. The linkage mechanism is investigated in order to emphasize: (1) the role of the database system, (2) the role of the graphics system and (3) the role of the operating system. In addition, the attributes manipulation and the sequence used for passing parameters from one system to another is given. This work has indicated two directions of linkage, the first concerns a binding from the graphics to the database system and the second represents a binding in the opposite direction. By comparing the linkage approach with other binding approaches, it can be fairly concluded that the linkage is quite reasonable for small computers because of the following advantages: (a) straightforward implementation, (b) no need for a global interface, (c) economical storage size is required since only one system exists in the main memory at a time.
SALAMA
Eventually, the implementation of the proposed technique on a small computing system has confirmed its applicability as well as it has exposed the basic requirement needed in order to facilitate the linking mechanism. REFERENCES
[l] S. K. Chang and T. L. Kunii. Pictorial data-base systems. IEEE Comput., pp. 1321 (November, 1981).
[2] F. A. Brings et al. PUMPS architecture for oattern analysis anh-image database management. IEEE Trans. Comput. C-31(10), 969-983 (October, 1982). [3] S. E. Madnick and J. J. Donvan. Operating Systems. McGraw-Hill, New York (1974). [4] F. Palermo and D. Weller. Picture building system. IBM Research Rept RJ2436, San Jose, Calif. (January, 1979). [5] K. Hwang and K. S. Fu. Integrated computer architecture for image processing and database management. IEEE Comput., p. 51-60 (January, 1983). [6] Lorus l-2-3 User’s Manual. Lotus Development Corp., Cambridge (1983). [7] S. K. Chang, N. Donoto, B. H. McCormick, J. Reuss and R. Rocchetti. A relational database system for pictures. Dept of Information Engineering, Illinois University of Chicago Circle (1977). [8] N. S. Chang and K. S. Fu. A relational database system for images. Rent TR-EE 79-28. Deot of Electrical Engineehng, P&due University (May: 1979). [9] R. Williams. On the application of relational data structures in computer graphics. IFIP Conf. Proc. (1974).
WI D. W. Weller and F. P. Palermo. Database require-
ments for graphics. IBM research rept RJ2435, San Jose, Calif. (January, 1979). Pll R. A. Lorie, R. Casajuana and J. L. Becerril. GSYSR: relational database interface for graphics. IBM Research Reot RJ2511. San Jose. Calif. (April. 1979). WI W. G. Moorhead. GXRAM: relationaldatabase interface for graphics. IBM Research Rept RJ1735, San Jose, Calif. (1976). [I31 R. Williams and G. M. Giddings. A picture building system. IEEE Trans. Sofrware Engng SE-2(l), 6266 (March, 1976). 1141D. M. McKeown Jr and D. Raj. Reddy. A hierarchical symbolic representation for an image database. Proc. IEEE Workshop on Picture Dora Description and Man agemenr, pp. 4@44 (April, 1977). [I51 G. Enderle, K. Kansy and G. Pfaff. Computer Graphics Programming. Springer Verlag, Berlin (1984). iI61 W. M. Newmann and R. F. Sproull. Principles of Interactive Computer Graphics. McGraw-Hill, New
York (1982). 1171N. S. Chang and K. S. Fu. Picture query language for pictorial ,__ . data-base _^^_. system. IEEE Compur., pp. 2330 (November, IYII). [18] T. L. Kunii, T. Amano, H. Arisawa and S. Okada. An interactive fashion-design System; INFADS. Compur. Graphics l(4), 297-302 (1980). [19] J. D. Foley and A. Van Dam. Fundamentals of Inreractive Computer Graphics. Addison-Wesley, Reading,
Mass. (1982). [20] WANG Professional Cornpurer User Manual for Disk Operating System. Wang Lab., Mass. (December, 1983). [21] Adi J. Khambata. Microprocessor/Microcomputer Architecture Software and Svsrem. Wilev. _ New York (1982). ” [22] DBASE II User Manual. Ashton-Tate, Calif. (1981). [23] AuroCAD User Manual. Autodesk Inc., San Jose, Calif. (1984).
Binding database and interactive graphics systems (241 C. J. Date. An Introduction to Dambase Systems. Addison-Wesley, Reading, Mass. (1977). APPENDIX The Procedural Operations for Linkage from DBASE II to AutoCAD Two illustrative queries are considered: (1) Adding a new part to Table 3 from a supplier who is already existing in table 4.
This query needs programming of three command files: I. The first command file will: 1. Accept a supplier number and a part number from the user. 2. Search the SP relation to find out the record that satisfies the entered supplier number. 3. If such a record is not found, then the program is terminated. Otherwise, the P relation is searched for a record satisfying the entered part number. 4. If such a record is found in the P relation, then the program is terminated since this new part is already defined. Otherwise, the system allows the user to enter the contents of the fields of the new record, and then appends the new record to the P relation. II. The second command file will: 1. Search for a relation whose name is the same as the content of the SHAPE field of the new record. 2. If such a relation is found, then the ADDing program is terminated since the drawing shape of the new added part is already defined. Otherwise, a new relation, with the same structure as any ELEMENT relation, is created where its name is the same as the content of the SHAPE field of the added record. 3. Allow record(s) insertion into the created relation, so that for each entered record, the following steps are repeated until the end of the relation. 3(a) Check whether a relation with the same name as the content of the ELEMNAME field is already created or not. 3(b) If such a relation is not found, then a new relation having a name as the content of the ELEMNAME field is created. Then, the records of that relation which represent the logical picture are inserted. 3(c) Go to the next record of the named ELEMENT relation. III. The last command file is to return the control to the main menu without creating any input tiles. (2) Retrieving the shapes of all the parts that satisfy a certain condition (e.g. part(s) supplied by a supplier whose SNO = Sl). In this case, the input text files are created by the DBASE II command “SET ALTERNATE TO (filename)” which creates a file for saving the text edited on the screen. A new data can be appended to that file by the DBASE II command “SET CONSOL ON” [22]. For each retrieved part, an input file is created to hold the graphical element(s) of that part, One more input file which does not contain any graphical data, will be created at first. This input contains the data elements required to start up the AutoCAD program. Such data elements are: (1) drive name at which the AutoCAD overlay files can be found; (2) AutoCAD menu option number corresponding to begin new drawing; (3) a pseudo-drawing file name; (4) SCRIPT (filename) which is the name of the second input file which holds the graphical element(s) of the first retrieved part. Each subsequently created input file will correspond to a retrieved part and it contains, at its end, the name of the
279
next input file. The last input file will contain, at its end, instead of the next file name, the number of AutoCAD menu option corresponding to EXIT AutoCAD. The AutoCAD will accept its input from the first input file which will chain the other input file(s). The AutoCAD treats the chained input file(s) as SCRIPT field which is an AutoCAD feature [23]. So, the batch file must change the extension names of such files to be SCR instead of .TXT. The retrieval program which has been used to answer this query, consists of the following four command files. I. The first command file must: 1. Accept two entitites from the user; a relation name and a search condition. 2. Check whether the requested relation is the SP or P. If it is neither SP nor P, it should indicate an error message. Otherwise, if the requested relation is the SP, then it will be searched for a record satisfying the entered search condition 3. If such a record is not found, then the system indicates that there is no record satisfying this condition and returns the control to the main menu without creating any input files. Otherwise, make the given search condition be the content of the PNO field of the fetched record. II. The second command file will: 1. Search, the P relation, for a record satisfying the search condition (entered or modified). 2. Once such record is found, the first input file is created as discussed before. 3. Extract the nongraphical data of the fetched record. The contents of the PNAME, WEIGHT, and CITY fields, are the nongraphics data. III. The third command file will: 1. Search for a relation having the same name as the content of the SHAPE field of the fetched record. 2. Once such a relation is found, create an input file whose name is listed in the first created input tile. 3. Store the extracted nongraphics data in that file but in a form suitable to be executed by the AutoCAD TEXT command. 4. For each record found in the corresponding ELEMENT relation, the following operations are repeated until the end of that relation: (a) Search for a relation having a name as the content of the ELEMNAME field. (b) once such relation is found, translates all the occurrences of its XPOS and YPOS fields by the XTRANS and YTRANS fields of the used ELEMENT relation. The translated points are Xnew = XPOS + XTRANS and Ynew = YPOS + YTRANS. (c) Append the translated points to the used input file. They must be in a suitable form so that they can be. accepted as an AutoCAD LINE command. (d) Append also the AutoCAD command DELAY 1000, to delay the execution of the next command to AutoCAD. If the end of the corresponding ELEMENT relations is reached, then append to the used input file, the AutoCAD command QUIT Y. VI. The last command file must: 1. Check whether the relation requested before, has more records satisfying the entered search condition or not. 2. If none found, then the previous created input file will be the last input file. Accordingly, it is appended by the AutoCAD menu option number corresponding to EXIT AutoCAD and the control is returned to the operating system. 3. Otherwise, the following steps should be repeated until no more records satisfying the search condition (modified or not) are found.
M.
280
ZAKI
and R.
3(a) Append to the preceding input file the AutoCAD menu option numner which corresponds to begin new drawina. the content of the SHAPE field of the fetched record and eventually the next input file name. 3(b) Extract the nongraphical data that corresponds to the processed record. 3(c) Create an input file to maintain the extracted nongraphical data. II
SALAMA
3(d) Search for a relation that has the same name as the content of the SHAPE field of the fetched record. 3(e) For each record found in the corresnondina ELEMENT. relation, get the ELEMNAME td identrfy the relations that describe the required object. 3(f) After making the necessary translation, store in the input file the X- and Y-attributes of the required objects.