Spatial Management of Data

8/2/2019 Spatial Management of Data

1/20

Spatial Management of DataCHRISTOPHER F. HEROTComputer Corporation of America

Spatial data management is a technique fo r organizing and retrieving information by positioning it ina graphical data space (CDS). This graphical data space is viewed through a color raster-scan displaywhich enables users to traverse the GDS surface or zoom into the image to obtain greater detail. Incontrast to conventional database management systems, in which users access data by askingquestions in a formal query language, a spatial data management system (SDMS) presents theinformation graphically in a form that seems to encourage browsing and to require less priorknowledge of the contents and organization of the database.This paper presents an overview of the SDMS concept and describes its implementation in aprototype system for retrieving information from both a symbolic database management system andan optical videodisk.Key Words and Phrases: computer graphics, man-machine interaction, database query languages,graphics languagesCR Categories: 3.7, 8.2

1. INTRODUCTIONSpatial data management is motivated by the needs of a growing community ofpeople who have to access information in a database management system(DBMS) but who are not trained in the use of such systems. The information ina spatial data management system (SDMS) is expressed in graphical form andpresented in a spatial framework, so that the information is more accessible andits structure more obvious than in a conventional DBMS. In this way a user canfind the information he seeks without having to specify it precisely or knowexactly where in the DBMS it is stored.A user retrieves data from SDMS by examining a flat surface upon whichpictorial representations of the data are arranged. This approach permits manytypes of questions to be answered without the need for a keyboard, although aconventional symbolic query language is also provided.The graphical data space (GDS) of SDMS is accessed through a set of threecolor raster-scan displays, as illustrated in Figure 1 (page497). The leftmost ofthe three screens presents a world-view map of the entire data surface. APermission to copy without fee alI or part of this material is granted provided that the copies are notmade or distributed for direct commercial advantage, the ACM copyright notice and the title of thepublication and its date appear, and notice is given that copying is by permission of the Associationfor Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specificpermission.The work reported herein was sponsored by the Defense Advanced Research Projects Agency underContract MDA903-78-C-0122. The views and conclusions contained in this document are those of theauthors and should not be interpreted as necessarily representing the official policies, either expressedor implied, of the Advanced Research Projects Agency or the U.S. Government.Authors address: Computer Corporation of America, 575 Technology Square, Cambridge, MA 02139.0 1980ACM 0362-5915/80/1200-0493 00.75

ACM Transactions on Database Systems, Vol. 5, No. 4, December 1980,Pages 493-514.


2/20

494 * Christopher F. Herotmagnified portion of this data surface is simultaneously displayed on the mainscreen in the center. The location on the data surface of this magnified portion isindicated by a highlighted rectangle on the world-view map. The user can controlwhich portion of the data surface appears on the main display by pressing on thejoystick shown in the users left hand, in the foreground of the figure. Pressingthe joystick in any given direction causes the users magnified window to move inthat direction over the data surface, and this motion is reflected in a correspondingmotion of the highlighted rectangle on the world-view map.The simultaneous presentation of a world view and a detailed view of the datasurface ensures that the user is always aware of his current location in thedatabase. It also aids in finding a region of interest in a very large database.The data presented to the user on the main display can come from a variety ofsources. The three sources described in this report are(1) images stored as bit arrays on a digital disk,(2) a symbolic DBMS,(3) an optical videodisk.Tools are provided which allow the user or the database administrator to establishconnections among data from these sources.The use of the system is best illustrated through an extended example; one isgiven in Section 2. Section 3 contrasts SDMS with conventional DBMSs; Section4 compares SDMS with previous work that combines the use of computergraphics and databases; Section 5 details the use of the optical videodisk forstorage and retrieval of analog video information; Section 6 describes someadditional features of the system for defining the relationship between graphicaland symbolic representations of data; Section 7 describes SQUEL, the querylanguage that allows the use of typewritten queries with graphical retrieval,Section 8 gives a brief account of the progress on the implementation of theSDMS prototype; and finally, Section 9 presents some preliminary conclusionsabout the overall effectiveness of spatial management of information.2. EXAMPLEThis section illustrates the use of SDMS as an interface to a symbolic DBMS.The user in this example is examining a database of ships. This databaseoriginated as a conventional database managed by the INGRES database man-agement system [7]. A fragment of the SHIP relation in the DBMS is shown inFigure 2.The procedure by which the database administrator produced the graphicalrepresentation used in the example is described in Section 2.2.2.1 Retrieval of DataFigures 3 through 7 (pages 498-500) illustrate how SDMS is used to retrieveinformation from the database.Figure 3 shows the world-view map which is presented on the leftmost of thethree screens. It is an all-encompassing view of the data laid out on the graphicaldata surface. The map has been divided into two rows, one for each of the twocountries having ships in the database. Each row is further divided into columns,ACM Transactions on Database Systems, Vol. 5, No. 4, December 1980.


3/20

Spatial Management of Data - 495uic

NO0001NO0002NO0003NO0004NO0005NO0006NO0007NO0008NO0009NO9010NO0011NO9012NO0013NO9014NO0015NO0016NW017NW018NO0019NW020NO0021NO0022NO9023NO0024NO0025NO0026NO0027NO0028NO0029NO0030NO0031NO0032NO0033NO0034NO0035NW036NOQO37NOQO38NCQO39NO0040NW41NO0042No0043NO0044NOQO45

namCONSTELLATIONKENNEDY JFKITTY HAWKAMERICASARATOGAINDEPENDENCELOS ANGELESBATONROUGEPHILADELPHIASTURGEONWHALETAUTOGGRAYLINGPOGYASPROSUNFISHCALIFORNIASOUTH CAROLINADANIELS JWAINWRIGHTJOUETTHORNESTERETTSTANDLEY WHFOXBIDDLELEAHYYARNELL HEWORDENDALETURNER RKGRIDLEYENGLANDHALSEYREEVESADAMS CFKING JLAWRENCERICKETT CVBARNEYWILSON HBMCCORMICK LTOWERSSELLERSROBISON

We nat irCS beam readycv us NABC 130 1cv us NABD 130 1cv us NABE 130 2cv us NABF 130 5cv us NABG 130 1cv us NABH 130 1SSN us NAB1 33 1SSN us NABJ 33 1SSN us NABK 33 1SSN us NABL 32 1SSN us NABM 32 1SSN us NABN 32 1SSN us NAB0 32 1SSN us NABP 32 1SSN us NABQ 32 1SSN us NABR 32 1CGN us NABS 61 1CGN us NABT 61 1CG us NABU 55 1CG us NABV 55 1CG us NABW 55 1CG us NABX 55 1CG us NABY 55 3CG us NABZ 55 1CG us NACA 55 1CG US NACB 55 1CG us NACC 55 4CG us NACD 55 1CG us NACE 55 1CG us NACF 55 1CG us NACG 55 1CG us NACH 55 1CG us NACI 55 1CG us NACJ 55 1CG us NACK 55 3DDG us NACL 47 3DDG us NACM 47 1DDG us NACN 47 1DDG us NACO 47 1DDG us NACP 47 1DDG us NACQ 47 1DDG us NACR 47 1DDG us NACS 47 1DDG us NACT 47 1DDG us NACU 47 1

Fig. 2. Ship database.

one for each class of ship. Within each column, each ship is represented by acolored shape, referred to as an icon.The color of each icon indicates the ships readiness, one of the attributes ofeach ship in the symbolic database. Green indicates the highest readiness,followed by yellow, orange, and red.ACM Trsnssctioas on Database Systems, Vol. 5, No. 4, December 1980.


4/20

496 * Christopher F. HerotThe size of each icon is a function of the beam of its associated ship. This is

most apparent among the Russian carriers, located in the lower left corner of thedata surface.In the section in the center of the top row, one can see a highlighted rectangle,which indicates the portion of the data surface that is shown in the magnifiedview presented on the main display. The position of this rectangle, and thus theportion of the data surface shown on the main display, is controlled by thejoystick shown in Figure 1.Figure 4 shows the main data display which appears on the center screen.Notice that while the position and color of the ships are the same as in thehighlighted rectangle of the world-view map, the magnified view is more detailed.The icons have a more detailed shape, and beneath each shape are three textstrings, which give the ships international radio call sign, name, and commanding

officer.Given this graphical view of the symbolic database, let us see how a user wouldgo about retrieving information on a specific ship, in this case the Daniels. Tostart, he pulls the joystick down toward himself, indicating that he wishes tomove the magnified view toward the bottom of the data surface. When theDaniels is in the center of the screen, as in Figure 5, he releases the joystick.Now, to get a more detailed view, he twists the joystick clockwise, instructingthe system to expand the magnification of the picture shown on the screen. Oneinstant in this zooming process is captured in Figure 6. Once the machine hasmagnified the image, it adds more detail, as shown in Figure 7. The outline of theship becomes more detailed, and the space under the ship is filled with values ofattributes from the symbolic database.At this point the user has a choice of actions. He can move laterally across thedata surface and examine similarly detailed views of adjacent ship icons. He cantwist the joystick in the counterclockwise direction to return to the less detailedviews of Figures 5 and 6. Or he can, if the database administrator has providedfor it, once again twist the joystick clockwise and magnify the view in Figure 7,getting a still more detailed icon with yet more attribute values displayed.2.2 Creation of the Graphical Data SurfaceThe preceding paragraphs described how one might use a graphical view of asymbolic database to retrieve some information. In order to construct such aview, the database administrator must first describe to the system how each iconshould appear and then instruct the system to create a data surface of icons forselected tuples in the DBMS.

2.2.1 Icon-Class Description. The SDMS provides the database administratorwith a tool for describing the appearance of each icon as a function of attributesof tuples in the DBMS. That tool is the icon-class description language (ICDL).It consists of a series of statements, each of which accepts some attribute valueand performs some graphical operation. The ICDL that was used to generate theicons shown in the preceding example is given in Figure 8.The position statement determines the placement of the icon on the datasurface. In the example it maps the ships type into x coordinates and itsACM Transactions on Database Systems, Vol. 5, No. 4, December 1980.


5/20

Figure 1. User Station

Figure 3. World-view map


6/20

Figure 4. Magnified view of data surface

Figure 5. Magnified view with "Daniels" centered


7/20

Figure 6. Zoomed in view of data surface

Figure 7. More detailed view of data surface


8/20

Spatial Management of Data 501

icon class cluster(r)beginmaximum size is (110,60);position is(case rkype begin0,: 800SSN: 1600SSBN: 1600SSGN: 1600CGN: 2500CG: 2500C*: 2500DDG: 3200FF: 3200AGI: 3200AO: 4000default: 1600end, case mat beginus:1200UR:2OcOdefault:2500end);template icon case r.type begin(-iv: carrierSW: subSSBN: subSSGN: sub

CGN: cruiserCG: cruiserCA: cruiserDDG: destroyerFF: destroyerAGE destroyerAO: oilerdefault: cruiserend;scale is r.beam*2 percent;color of region 1 is case rready begin1:green2:yellow3:orange4:reddefaultgrayend,attribute region r.nam from (5,16) to (70,28);attribute region rims from (5,28) o (70,40);attribute region r.conam from (5,40) o (70,52);end,

Fig. 8. Icon-class description.

nationality into y coordinates. The template statement specifies the shape of theicon by selecting among a set of pictures that have previously been drawn by thedatabase administrator. The scale statement specifies the size of the icon as afunction of the beam of the ship. The color statement specifies the color of eachACM Transactions on Database Systems, Vol. 5, No. 4, December 1980.


9/20

502 l Christopher F. H&ot

ship according to its readiness. Finally, the three attribute region statementsplace the values of the ships name, international radio call sign, and commandingofficers name into the specified locations in the icon.

2.2.2 The Association Statement. Having given the rules for the appearance ofeach icon, the database administrator creates the graphical representation byusing the associate statement. This causes SDMS to select particular tuples froma specified relation in the database and to create icons from them on the basis ofthe designated icon class description.To generate the graphical data surface of the preceding example, the databaseadministrator would type

associate ship using clusterThis causes SDMS to retrieve the tuples from the relation SHIP and pass themone at a time to a module which interprets the ICDL cluster, using the valuesof the attributes of the tuple. For each such tuple an icon is created on thegraphical data surface.The associate statement also permits the use of a qualification to select tuples.For example, a graphical data surface containing icons for those ships having areadiness of other than 1 could be created by typing

associate ship using cluster where shipready != 1This allows the combination of the capabilities of symbolic and graphic retrievalin searching for information.3. CONTRAST WITH CONVENTIONAL DBMSsAs may be seen from the foregoing example, an SDMS offers several advantagesover conventional keyboard-oriented DBMSs, including those offering naturallanguage or English-like user interfaces. In this section six such advantages arediscussed:(1) Motion through the database is simple and natural.(2) The database is its own data dictionary.(3) The presentation of the data encourages browsing.(4) The placement of the data can convey information.(5) Graphics can be used to convey information.(6) The system can accommodate many unique data types, such as photographs.3.1 Motion ControlsThe joystick of SDMS provides a simple and natural means of moving throughthe database. By using one control, the joystick, the user can explore the entiredatabase. On the other hand, symbolic query languages, such as QUEL [4],require the use of a special syntax and semantics. Even in natural-languagesystems, where the syntax is widely known and the semantics relatively intuitive,the user must learn the structure and contents of the database before he canfind anything. By contrast, the data in an SDMS can be displayed in a mannerthat makes the contents and structure readily apparent and does not require anyprior knowledge of the structure of the database in order to retrieve informationfrom it.ACM Transactions on Database Systems, Vol. 5, No. 4, December 1980.


10/20

Spatial Management of Data 503The level of abstraction at which the data are examined is similarly easy tocontrol. Twisting a knob zooms the picture and thus specifies the level of detailwhich is displayed, allowing the user to see global attributes, such as the number

of objects in a set, without the burden of utilizing separate functions for aggre-gation. In addition, if the database administrator has set up more elaborateabstractions, these can be invoked by the user by the same simple mechanism,requiring no additional knowledge on his part.When dealing with very large databases, this control of detail makes it possiblefor the user to see the entire database on the world-view display, even if there aremore elements in the database than can occupy discrete positions on the televisionscreen. The database administrator need merely define an abstraction whichgroups the data elements together in some suitable manner. For example, adatabase of ships might be grouped according to hull type. The more abstractviews of the GDS would then display the groups instead of the individualelements, allowing the user to see the entire database and move quickly to thelocation of some particular area of interest. Once he had centered that area onthe screen, twisting the knob would cause the individual elements to appear.3.2 The Graphical Data Space As Its Own Data DictionaryA conventional DBMS requires the use of a data dictionary to inform the user ofthe structure of the database. Even natural-language user interfaces suffer fromthe problem of educating the user as to what queries may be answered from theinformation contained in the database. In contrast, the graphical data space ofSDMS is its own data description. Rather than specify a relation and attributename, the user merely traverses the data surface until he reaches the desiredinformation, at which point the data are laid out in front of him.Data types are shown by example. As there will be many such examplesdisplayed on the data surface, they serve not only to display the data type thatis permitted, but also to reveal the values of the data that are typically used. Thisproperty informs the user of the ranges of the data or the shades of meaningoften obscured by attribute names such as remarks or comments. Since thevalues of such attributes are displayed on the screen, the uses made of such fieldsmay be readily ascertained.3.3 BrowsingThe user of an SDMS is almost always presented with a display that gives himmore information than he immediately needs. Within this presentation, findingthe required information is facilitated by the distinctive visual qualities that canbe imparted to the data. At the same time, the unsolicited surrounding data makeit possible for the user to browse through the database. This is a difficult activityin a conventional database system, where every piece of data must be requestedexplicitly. While a small database may be printed out and examined, the lack ofany mechanism for placing related data together would make such a techniqueimpractical for very large databases. Likewise, it would be very tedious to submitrepeated queries, and such a technique would be ineffective if the user were notalready familiar with the contents and structure of the database.In contrast, SDMS allows the database administrator to arrange the informa-

ACM Transactions on Database Systems, Vol. 5, No. 4, December 1980.


11/20

504 * Christopher F. Herottion in the database according to any chosen attributes. Once the user haspositioned his window in the vicinity of the data being sought, he can browsethrough the surrounding area, letting the appearance of the icons determinewhere he focuses his attention.3.4 Using Icon Position to Convey InformationThe placement of a particular icon can be used to aid in recalling a particulardatum, in much the same way that a person finds some needed information in hisoffice by recalling where he put the piece of paper on which it was written.The placement of an icon may also convey information directly. In the exampleof the preceding section the location of each ship indicated its nationality andtype. A personnel database could be arranged according to seniority or salary.Each organization could be displayed in a separate part of the GDS, allowing theuser to select whatever arrangement suited his specific query. He could thenobserve the world-view map to get an overall picture, such as the number of itemsin each category, and he could move his magnified window over some particulararea to look at exceptional, extreme, or average values.3.5 Graphic RepresentationsGraphic representations are often the most vivid means of conveying information,especially for aiding in the perception of trends in large aggregations of data. Themost familiar forms of this technique are the histogram and graph, wherenumerical data are displayed in graphical form. The graphical output facilities ofSDMS make such display of numerical data possible as a natural extension of thesystem.Graphical representations may also be used to advantage in displaying trendsin nonnumerical data. For example, a database of ships could be displayed againstthe background of a map, with the wake behind each ship indicating its speedand direction. With such a display it is easy to spot trends that otherwise wouldbe hard to formulate into symbolic queries, such as a trend in a large number ofships heading for the Middle East.3.6 New Data TypesAn SDMS is not restricted to data that originate as numbers and characterstrings. The raster-scan output devices and digital storage of graphical dataprovide a natural means of storing images such as photographs. The prototypeSDMS provides an interactive graphical editor, which allows a user to annotatea data surface or, without requiring any special artistic talent, to create diagramsand illustrations.The prototype implementation also includes an optical videodisk, which can becontrolled through SDMS to provide storage for a very large number of videoimages.4. PREVIOUS WORKThe use of graphics to manipulate a database dates back to the earliest days ofcomputer graphics. In 1963 Ivan Sutherlands SKETCHPAD [S], one of the firstcomputer graphics programs ever written, illustrated how interactive graphicsACM Transactions on Database Systems, Vol. 5, No. 4, December 1980.


12/20

Spatial Management of Data 505could be a natural mechanism for creating and manipulating geometric descrip-tions. Spatial data management makes the mechanism of graphical manipulationand display available to the larger application of dealing with nongeometric data.The icon-class description mechanism of SDMS allows data to be displayedspatially even when those data contain no explicit spatial information. ThusSDMS is not limited to geographic or geometric data but can spatially displayany data for which the database administrator can define a suitable transforma-tion. This transformation can be accomplished within the icon-class descriptionlanguage without resorting to an ad hoc escape to a separately compiledprogramming language, which is often required in other systems.Since SKETCHPAD there have been many computer systems that haveexploited the interaction of graphics and databases, but unlike SDMS orSKETCHPAD, which use graphics as a means of interacting with a database,these systems typically provide a DBMS as the front end and produce graphicsas the result.One well-known system in a research environment [9] provides the user witha relational database in which he can store graphical descriptions. These descrip-tions may contain mixtures of graphical primitives and references to previouslydefined objects, giving the user a powerful picture-building facility. By using aninteractive program that edits the database, the user can easily alter his picture.The authors show how this technique could be used to combine graphical andsymbolic data in service of such applications as an illustrated catalog of machineparts.While the SDMS prototype provides similar facilities, extending them toinclude hand-drawn raster data, the emphasis of the system is not on makingpictures but on using those pictures to access a database. Although the currentimplementation of the system does use a DBMS in generating its graphics, theuser is encouraged to employ this mechanism as a means of accessing his ownsymbolic data. The graphics mechanism is superimposed on the DBMS andtherefore requires no modification of the users original symbolic data, allowingSDMS to be used for accessing an existing (possibly shared) database. Since thedisplay mechanism is external to the database, it is possible to define multiplegraphical views of the same date.Another database system that employs graphics to retrieve information isCUPID [5], which allows the user to formulate queries by manipulating graphicalsymbols. Unlike SDMS, where the graphical symbols represent the completecontents of the database, the symbols in CUPID represent the various primitiveoperations that can be performed on the data. CUPID is therefore a graphicalquery language rather than a graphical view of the data and cannot be directlycompared to SDMS.A database retrieval mechanism to which SDMS does invite comparison isQuery by Example (QBE) [lo]. A user of QBE enters his query by showing theform of the intended result. The assumption of this approach is that such a formis easier for the novice user since it does not require him to make the mentaltransformation between the different forms of a query language and the result ofthe query. SDMS shares that assumption and carries it a step further byeliminating the query step altogether and allowing the user to see the actual data.



13/20

506 * Christopher F. HerotDigltal Key Map

rm

Fig. 9. Spatial data.

Furthermore, the data in SDMS are represented spatially and graphically, makingtrends in the data and relationships among the individual elements more visible.5. OPTICAL VIDEODISKThe Computer Corporation of Americas SDMS prototype incorporates an opticalanalog videodisk player. Optical videodisks have a capacity of 54,000 images,which can be viewed either as discrete photographs or in sequence as a motionpicture. The same number of images stored on a conventional magnetic digitaldisk would require 10 bits, or 100 3330~type disks.The spatial, graphical access to information of SDMS provides a naturalmechanism for retrieving spatial or graphical information stored on the opticalvideodisk. Two approaches are employed for accessing videodisk images.Inherently spatial data, such as a map, are divided into sections small enoughto be stored as individual video frames. The user selects a particular framethrough the use of a digitally stored map, as shown in Figure 9. He can traversethis data surface as he would any other graphical data surface. When he zoomsin to get a closer look, the system displays the videodisk image from the cor-responding position.A second method of accessing videodisk data is used for accessing photographsthat are not spatially related, as in the case of photographs of employees in apersonnel database. In such a case, illustrated in Figure 10, the user once againbegins with a digitally stored graphical data surface. This surface is populatedwith discrete icons, one for each frame to be, accessed. By zooming in on aparticular icon, the user can see the associated frame. A variation on this schemeallows one icon to be associated with a sequence of videodisk images. When theicon is selected, that sequence may be examined as a motion picture or asindividual photographs, with the user specifying the location in the sequencewhere he wishes to begin.The mixture of analog and digital video in SDMS also makes possible theediting of data stored on the read-only videodisk. As the output of the videodiskcan be directed to the center display screen at the same time that it is displayingdigitally stored information, the two can be superimposed, providing a means ofoverlaying analog video with digital annotations. Alternatively, the analog videomay be digitized and operated upon as bit-array data.ACM Transactions on Database Systems, Vol. 5, No. 4, December 1980.


14/20

Spatial Management of DataDigital Data Surface

* 507

Fig. 10. Photographic data.

6. DEFINING GRAPHICAL VIEWSThis section provides additional details on the relationship between symbolic andgraphical representations of data in SDMS. It introduces several features notmentioned in the example of Section 2.6.1 Dual Representation of Data

6.1.1 Entities and Icons. The SDMS allows the tuples of a relation in asymbolic database management system (DBMS) to be represented in a graphicaldata space (GDS). The graphic representation of a tuple is an icon. Those tupleshaving a graphic representation are distinguished from other tuples and are calledentities. Each entity may be represented by more than one icon. Conversely, eachicon may be a representation of more than one entity.A goal of SDMS is to allow a user to refer to data via graphical methods, suchas spatial search, or via symbolic methods, such as using a QUEL retrievalstatement. To achieve this, SDMS provides a mapping between each entity andits icon. This mapping is provided via a link which logically connects the two.When an entity and icon are linked, a selection of one implies a selection of theother. In the query language of SDMS, the two selection methods may becombined through the use of links.Links are created by associating a tuple with an icon, which makes the tuplean entity. There are two types of associations in SDMS. The first type, thespecific association, links a specific tuple to an existing icon. It is most useful forrecording symbolic information about visual data, such as entering a descriptionof the subject matter of a photograph.The second type, the class association, generates new icons for one or moretuples in a relation. The class association was used to create the graphical viewof the ships database, described in Section 2.Specific associations are most useful for entering symbolic data for locatinginformation that is inherently graphical, while class associations are most usefulfor creating graphical data for locating information that is inherently symbolic.1 n the Computer Corporation of America implementation of SDMS, the DBMS used is INGRES,a relational database system [4] . The query language of INGRES is called QUEL.



15/20

508 - Christopher F. Herot

The class association eliminates the need for explicitly creating and linking anicon to each tuple by providing an automated mechanism for doing so.

6.1.2 Specific Associations. A specific association between a tuple and an iconcreates a link between the two. The tuple must already exist in some relation atthe time of the association. The icon must also exist in the GDS at the time ofthe association. Such icons will often be photographs or manually constructeddiagrams. By creating tuples and linking them to such an icon, the user can thenlocate specific icons by the use of symbolic queries. For example, a database ofpaintings could be accessed by means of the artist, year, nationality, genre, etc.,of a particular work.Specific associations may also be used in conjunction with subicons (describedin Section 6.4) to allow a class association to specify individual photographs. Forexample, the icons for the employees in a personnel database could each includethe employees photograph.

6.1.3 CZass Associations. The class association is the principal tool for con-necting the GDS to the DBMS. It is intended primarily as a tool for the databaseadministrator (DBA).A class association between a relation and the GDS causes the creation of icons that graphically represent the tuples of the relation. The icons are placed in theGDS. It is possible to associate only a subset of the relation by supplying aqualification that determines which tuples are to be represented. It is also possibleto have the placement of the new icons restricted to a particular rectangularregion of the GDS. The effects of such an association are as follows.(1) For each tuple in the relation, an icon is created and inserted into the GDS.If a qualification was supplied, icons are created for only those tuples whichpass the qualification.(2) Each of these tuples and their corresponding icons are linked. The systemwill maintain the correspondence between the two as the database is updated.

When a class association is made, an icon-class description that tells exactlyhow to draw each icon may be specified. The icon class is essentially a picture inwhich certain parameters may vary each time the picture is drawn. Theseparameters include size, shape, color, position, and text strings. The values ofthese parameters may depend on the data in the entity being represented. Iconclasses are discussed in Section 6.2.When a class association is made, an explicit data dependence is establishedbetween each entity and its corresponding icon. This is manifested at first whenthe system draws these icons such that they reflect the data in the entity. Second,the data dependence serves to ensure that the icons that are created owing to aclass association will always reflect the tuples they represent, until the associationis explicitly broken. Hence, if an entity is updated, its corresponding icon isupdated. If an entity is deleted, its icon is erased. If new tuples are added to therelation, they become entities if they pass the qualification, and new icons arecreated to represent them. The result is that the GDS always contains a repre-sentation for the given relation. The GDS serves as an alternate way to view therelation.ACM Transactions on Database Systems, Vol. 5, No. 4, December 1980.


16/20

Spatial Management of Data 5096.2 Icon ClassesAn icon class is used in conjunction with a class association. While specific andclass associations are relatively simple and may be performed by ordinary SDMSusers, the icon-class description language (ICDL) is more complex and is meantto be utilized primarily by the database administrator.An icon-class description consists of a series of statements that specify theappearance of the icon. Each statement performs some graphical operation, suchas selecting a template picture, coloring some region, or inserting some text. Thevalues of arguments to an ICDL statement may be taken from attributes of tuplesretrieved from INGRES.

An icon constructed from an icon class may have its appearance defined atseveral levels of detail. This allows the zooming effect, as illustrated in Section 2,by which a user sees a more detailed version of an icon by magnifying it. The bit-array description for a single level of detail is referred to as an image plane. Thepictures for each image plane originate as templates, which are simply picturesdrawn by the database administrator on a special image plane reserved for thatpurpose. For example, the templates for ships might be drawn as follows: At thetopmost (least detail) image plane the ship appears as a small rectangle. Thesecond image plane has a rough silhouette with the ships name and radio callsign beneath it. The third (most detailed) image plane shows some of the shipssuperstructure, and the ships name, call sign, beam, draft, speed, etc., appearbeneath the picture. With such a description, a user who zooms in on such anicon will get more detail as he gets closer.Continuing with this example, we may want different drawings for differenttypes of ships. An icon class may include a rule for selecting among severaltemplates.The parameters of an icon that may be controlled by an icon-class descriptionare

(1) Maximum size: The maximum size of each icon may be specified to preventany one of them from becoming too large. Since relative size is a pictureparameter, it is a good protection.(2) Choice of picture: There may be several different pictures that serve astemplates, depending on the data in the tuple. In the example in Section 2.1,carriers had a different picture from destroyers. If more than one picture is given,a rule for deciding which picture to use must be provided.(3) Targetposition: The target position specifies the exact location for an iconwithin the GDS. SDMS does not let icons overlap, so if an icon can fit at thetarget position, it will be placed there. Otherwise, a location close to the targetposition is used.(4) Color: Any region of the template may be colored. In the example, thereadiness determined the color of each ship.(5) Size: The template given for the description of an icon class may be scaled.In the example the size was a function of the beam of each ship. The default sizeis the size of the original template, up to the maximum size for the icon class.(6) Orientation: The picture may be oriented by some arbitrary angle. Thedefault is the orientation of the original template.



17/20

510 * Christopher F. Herot(7) Text: Text may be added to the picture. This text may be a simple stringor it could be the data from one or more fields of the tuple.

6.3 Using INGRES DataEach icon in the GDS may reflect the data in the entity it represents. This isdone by making the data in the entity accessible from within the icon-classdescription. It is also possible to retrieve other tuples from any relation inINGRES, to aid in the description of an icon class. There are two statements forperforming retrievals. One is the get statement. The get statement is used whenone tuple is needed in response to a query, as in finding the beam of a particularship. If more than one tuple satisfies the qualification of the statement, an erroroccurs. The other statement is a for loop statement which is used to retrieve a setof tuples from a relation. This statement uses one or more statements that areexecuted once for each tuple retrieved. The for loop construct could be used toretrieve the previous positions of a ship from a track history relation. Eachposition could then be displayed as part of the wake of the ship.6.4 SubiconsAnother feature of an icon class is the ability to have subicons drawn within thearea of an icon. This feature allows the nesting of icons, displaying, for example,a subicon for each employee within a department that is represented by one icon.Subicons may be included to overlay portions of the picture for some or all levelsof detail.

The subicon differs from a normal icon in that(1) if the parent icon is moved, the subicons move with it;(2) if the parent icon is erased and its link broken, all of its subicons are erasedand their links are broken.6.5 GDS OperationsThe actual construction of a GDS is performed via an interactive graphical editor.This program allows the user or database administrator to select various graphicaloperations from a menu displayed on the right-hand screen. These operationsallow a picture to be created from a set of primitives, such as lines and rectangles,which can be combined with previously defined objects stored in a library. Thesepictures can be inserted directly into the GDS as data for use in charts anddiagrams, or they can be used as templates that will be further processed by theicon-class mechanism described above.Additional commands allow the database administrator to create new imageplanes and link them together in various hierarchies and networks. The graphicaleditor is described in detail in [2].7. SQUEL, THE QUERY LANGUAGE OF SDMSAlthough the usual mechanism for retrieving data from SDMS is the explorationof the GDS, there are occasions when a more conventional symbolic query facilityis indicated. This can happen if the user does not know where some particularicon is spatially located, although he can describe it symbolically as, for instance,when trying to find a ship with a particular name. The symbolic query facility isACM Transactions on Database Systems, Vol. 5, No. 4, December 1980.


18/20

Spatial Management of Data * 511also used by the database administrator to specify which tuples in a relation areto be displayed as icons in the GDS.The query language of SDMS is a combination of QUEL, the query languageof INGRES, and additions made for the graphical environment of SDMS. Thename SQUEL is a contraction of Spatial QUEry Language. Statements fromQUEL can be entered directly to SQUEL, as QUEL is a proper subset.The following commands have been added to the original QUEL commands toproduce SQUEL. Each of them accepts a standard QUEL qualification which isused to select particular tuples from a specified relation. The selected tuples arethen passed to SDMS, which performs the indicated graphic action. As icons arealways associated with tuples, these SQUEL commands can be used to locateand operate upon these graphical representations of information.

(1) find (tuple var) where (qual). Moves the user to the position occupiedby the specified icon. As entire regions can be icons at some level of abstraction,the find command can be used to place the user in the general area of a largegroup of icons.(2) blink (relation) where (qual). Blink finds all the tuples which satisfy(qual), Any icons in the current data surface which correspond to those tupleswill blink. They continue to blink until a null blink command is entered or untilthe user exits the system. The blink command is most useful in identifying whichmembers of a large group of icons meet some specified qualification. After issuingthe blink command, the user can move around the GDS, examining the blinkingicons in detail.(3) frame (relation) where (qual) . Similar to blink except that the appro-priate icons are framed, not blinked. Framing an icon is simply drawing arectangle around it. Framing is erased similarly to blinking.(4) associate (relation) using (icdl) where (qual). Creates an icon foreach tuple which meets the qualification. The appearance of each icon is deter-mined by the given ICDL. The associate command can be used to create newdata surfaces containing only those icons which meet a specified qualification.Thus, while the blink or frame commands allow viewing selected icons in thecontext of their original data surface, the associate command isolates these iconsin their own space.(5) change. Allows the user to update the database through SDMS. It informsSDMS that the user will point to a position within an icon. This signals that theuser will update the attribute displayed there. The user then enters the new valuefor the attribute, and the update is made immediately. This allows the user toupdate the database without requiring any symbolic specification of the target ofthe updating operation.

8. SDMS PROTOTYPE IMPLEMENTATIONThis section describes the particular prototype of SDMS implemented at Com-puter Corporation of America. An earlier implementation of SDMS, whichutilized manually entered images as opposed to data derived from a symbolicdatabase, was built at the Architecture Machine Group at the MassachusettsInstitute of Technology and is described by Donelson [3] and Bolt [l].

ACM Transact ions on Database Systems, Vol. 5, No. 4, December 1980.


19/20

512 Christopher F. Herot8.1 System EnvironmentThe prototype SDMS is written in the C language, running under the Unixoperating system on a DEC PDP11/70. The machine has 1.25 megabytes ofprimary memory and 176 megabytes of moving-head disk storage. Much of thememory is used for storage and manipulation of the bit-map representations oficons and GDSs.The GDS is viewed via a Lexidata frame buffer display. This display has itsown 480 X 640 x 8-bit memory, from which the image on the color televisionscreen is generated.8.2 ScheduleThe SDMS prototype implementation effort has been underway for about twoyears. The current version of the system provides all of the facilities described inSection 2 for moving about the graphical data surface and generating graphicalviews of symbolic data.The current implementation consists of approximately 60,000 lines of code.9. CONCLUSIONSThe response from visitors to our laboratory who have used the system has beeneathusiastic. Only a few seconds are required to learn to operate the controls.During the coming year several prototype systems will be installed, and a morerigorous evaluation will be undertaken, with realistic databases and subjectsdrawn from the intended user communities.Two limitations of the SDMS approach are evident at this stage, however, andpoint up the direction for future work.First, spatial location of information is best for those problems in which theformulation of a precise query is difficult. The technique encourages browsingthrough the data, allowing information to be found even when only a vaguespecification is possible. When a key can be precisely specified, it may be moreefficient to type that key directly into the system rather than attempt to recallthe spatial location of an icon. More research is needed to determine under whatconditions the spatial and symbolic modes are most favored. One would suspectthat the ideal combination would allow a mixture of graphical and naturallanguage queries, or would allow the user to manipulate the graphical represen-tations as a means of specifying a query.A second limitation is the required involvement of the database administratorin setting up the graphical views of the symbolic data. While the level of effortand expertise required is no more than that expended on setting up the datadefinition language of a conventional DBMS, it would be desirable to have thisactivity performed in a more automated manner. A major problem is that mostexisting DBMSs do not contain the notion of an entity, requiring the end user toconstruct descriptions of real-world objects out of multiple relations or files. Thisoperation is performed in SDMS by the database administrator when he specifiesin an icon-class description which relations contain the information to be used increating a particular icon class. A more general approach would use a higher levelquery language, such as Daplex [6], that contained such facilities, and a set ofACM Transactions on Database Systems, Vol. 5, No. 4, December 1980.


20/20

Spatial Management of Data * 513semantic data descriptions that could be used to select among alternative graph-ical interpretations.

REFERENCES1. BOLT, R. Spatial data management. DARPA Rep., M.I.T. Architecture Machine Group, Cam-bridge, Mass., 1979.

2. CARLING, Ft., KRAMLICH, D., AND FRIEDELL, M. Tech. Rep. CCA-79-25, Computer Corporationof America, Cambridge, Mass., June 1979.

3. DONELSON, W. C. Spatial management of information. ACM SIGGRAPH, 1978.4. INCRES REFERENCE MANUAL. Memo. ERL-M579, Univ. California, Berkeley, Calif., 1977.5. MCDONALD, N., AND STONEBRAKER, M. Cupid-The friendly query language. Memo. ERL-

M487, Electronics Research Lab., Univ. California, Berkeley, Calif., October 1974.6. SHIPMAN, D. The functional data model and the data language DAPLEX. Tech. Rep. CCA-79-

16, Computer Corporation of America, Cambridge, Mass., April 1979.7. STONEBRAKER, M.R., HELD, G.D., WONG, E. INGRES-A relational data base system. In Proc.

AFIPS, Vol. 44, AFIPS Press, Arlington, Va., 1975, pp. 409-416.8. SUTHERLAND, I. SKETCHPAD: A man-machine graphics communications system. In Proc.

AFIPS 1963 Spring Conf., AFIPS Press, Arlington, Va., pp. 329-346.9. WELLER, D., AND WILLIAMS, R. Graphic and database support for problem solving. ACM

SIGGRAPH 1976 Computer Graphics 20, (Summer 1976), 183-189.10. ZLOOF, M. Query by example. In Proc. AFIPS 1975 Spring Conf., AFIPS Press, Arlington, Va.,

pp. 431-438.

Received October 1979; revised December 1979; accepted March 1980


Spatial Management of Data

Documents

Transcript of Spatial Management of Data