IPR2016-01869 Ex. 1015
`Broadsign International, LLC Petitioner
` 1
`
`

`
`(_Z_cJ_}:_vy_1_'i_gl1_t_©.J.9.92 .by Macmillan Publishing Company
`A Divisioifof Macmillan, Inc."
`
`All rights reserved. No part of this book may be reproduced or
`transmitted in any form or by any means, electronic or mechanical,
`including photocopying, recording, or by any information storage and
`retrieval system, without permission in writing from the Publisher.
`
`Macmillan Publishing Company
`A Division of Macmillan, Inc.
`866 Third Avenue, New York, NY 10022
`
`Maxwell Macmillan Canada, Inc.
`1200 Eglinton Avenue East, Suite 200, Don Mills, Ontario M3C 3N1
`
`Macmillan, Inc., is part of the Maxwell Communication Group of
`Companies.
`
`Library of Congress Catalog Card Number: 91-45339
`
`Printed in the United States of America
`
`Printingnurnber
`3 4 5 6 '7 8 9 10
`
`Library of Congress Cataloging-in-Publication Data
`
`Macmillan encyclopedia of computers / Gary G. Bitter, editor in chief.
`p.
`cm.
`‘
`ISBN 0-02-897045-4 (set). — ISBN 0-02-897046-2 (vol. 1). — ISBN
`0-02-897047-0 (vol. 2)
`1. Computers—Encyclopedias.
`QA76.15.M33
`1992
`0D4’.03—dc20
`
`I. Bitter, Gary G.
`
`91-45339
`CIP
`
`The paper used in this publication meets the minimum requirements of
`American National Standard for Information Sciences—Permanence of
`Paper for Printed Library Materials. ANSI Z39.48—1984.
`
`4; 231995
`
`
` 2
`
`

`
`230
`
`DATABASE DESIGN, AUTOMATED
`
`input? What happens if a lightning bolt
`strikes a thermocouple? Will it destroy the
`data acquisition hardware? Will it also de-
`stroy the computer? Both can happen.
`The remote instrument approach is the
`best way to allow for
`the kind of high
`reliability just discussed, as the data acquisi-
`tion hardware is physically and electrically
`separated from the computer. The board
`approach is the most risky, but may be
`entirely acceptable if the installer is careful
`and knowledgeable.
`
`Pfioe
`
`Little needs to be said about price, except
`that each application has its price con-
`straints, and each different hardware ap-
`proach has a di.fferent price. Price must be
`weighed along with all the other factors to
`arrive at the best balance. In general, the
`boards are the least expensive, the remote
`instruments are the most expensive, and the
`proprietary board/remote instrument com-
`binations are intermediate. This is because a
`remote instrument must contain its own
`
`power supply and also a communication
`subsystem to talk to the computer.
`
`Software
`
`Software is an important part of the total
`picture, as none of these hardware devices
`can be used without it. Many of the afore-
`mentioned characteristics, such as speed,
`throughput, channel type capability, chan-
`nel number capacity, and (especially) ease of
`use, depend on the software as well as the
`hardware. This article is mainly about hard-
`ware, however.
`
`customer Support
`It is likely that sometime in the life use of any
`data acquisition equipment, the manufactur-
`er will have to be called for service or sup-
`port. This important factor should not be
`overlooked. One good way to evaluate com-
`panies in this regard is to pose some good
`hard application questions to them before
`buying. Another method is to ask for and
`follow up on references.
`
`SELECTING A DATA ACQUISITION BOARD
`
`To match application requirements to data
`acquisition boards, first collect the literature
`on likely candidates. Then consider each of
`the aforementioned factors in the order of '
`their importance to the application at hand,
`discarding candidates that do not meet the
`requirements. The list of candidates will nar-
`row to two or three by the time this process is
`finished. If this is the case, consult a col-
`league if possible on the relative merits of the
`remaining candidates. Review the list one
`more time, rating each candidate on each
`factor with a score pf 1 to 10, and then total
`the scores. The highest final score wins!
`
`Frederick A. Putnam
`
`DATABASE DESIGN, AUTOMATED
`
`A database system is a collection of related
`records stored in a manner that makes the
`storage and retrieval of the data very effi-«-
`cient. The four well-known data models for
`
`databases are the hierarchical, network, rela-
`tional, and object—oriented models.
`The oldest of .these models, the hierar-
`chical model, was established out of necessi-
`ty in the early 1960s without any prior
`formal study or definitions. Theoretically,
`the _many-to-many relationship type be-
`tween records (as when a strident takes many
`courses and a course has many students) is
`not permitted in the hierarchical model. The
`IMS Data Base Management System (DBMS)
`package is the oldest and most dominant
`hierarchical DBMS package.
`The network model is the product_of
`the’ Database Task .Group Com.mit_tee_,
`(CODASYL 1975). Its first version appeared -
`in 1961. This model permits all different
`-v
`types of connectivity: one—to-one, one—to-
`many,
`and many-to-many relationships
`(through the composition of two one—to-
`many relationships). Some network database
`packages are IDMS and IDMS/'R of Cullinet
`Software,
`IDS of Honeywell, DMS II of
`Unisys, DBMS 10 and 11 of Digital Equip-
`ment, and Image of Hewlett-Packard.
`
`
` 3
`
`

`
`DATABASE DESIGN, AUTOMATED
`
`231
`
`The theoretical foundation for the rela-
`
`tional database model was established by E.
`F. Codd in 1970 (Codd 1970). In this model,
`information is stored in a two-dimensional
`
`table called a relation. Each column repre-
`sents a field of the record and is called an
`
`attribute. Each row of the table represents a
`data record of the file and is called a tuple.
`All the elements of the table must be simple.
`In other words, no element of the table can
`be a table on its own. The reservoir from
`which the values of an attribute are drawn is
`
`called the domain of that attribute. A process
`called normalization is used for grouping
`information in these tables so that duplicate
`values of attributes are eliminated. These
`tables are constructed in such a manner that
`
`1. All the requirements of the client for
`whom the system is designed are satisfied.
`
`2. The relationship between attributes
`within a table or between attributes of differ-
`ent tables or between tables themselves en-
`ables the user to add new data to the data-
`bases or to delete data from the databases or
`
`to update data without causing any anomaly
`(inconsistency) within“ a database.
`
`Some well-known relational database
`
`packages are DB2 of IBM; Ingres of Rela-
`tional Technology; Oracle of Oracle, Inc.;
`Unify of Unify, Inc.; dBASE of Ashton-Tate;
`Rdbase 5000 of Microrim; Informix of In-
`formix Software, Inc.; and Paradox of Borland,
`Inc.
`
`The object-oriented data model uses the
`concepts of entities and objects. An object is
`a representation of an entity in the database
`system environment. An entity has an infi-
`nite number of properties, but an object will
`take only a finite subset of these properties to
`represent the entity in the system. An object
`encapsulates both the data and the opera-
`tions that can be performed on them. The
`operations are known as methods. Some
`examples of object-oriented database pack-
`ages are Vbase Integrated Object Oriented
`System of Ontologic,
`Inc.; GEMSTONE/
`OPAL of Serviologic; and ORION of Micro-
`Electronic and Computer Technology Corpo-
`ration.
`'
`
`In database terminology a record type
`
`means a file. In relational databases, record
`types are called relations, and fields are
`known as attributes. The record types in
`object-oriented databases are called objects,
`and the fields are called properties. In gener-
`al, a file has one or more candidate keys.
`Each candidate key is‘ a field or a group of
`fields that identifies a unique record within
`the file. Any of the candidate keys can be
`chosen as the primary key of the file; thus the
`primary key of a file identifies a unique
`record of the file. A foreign key is a field or a
`group of fields within a file that
`is the
`primary key of another file. The primary key
`is used to access a specific record from a file,
`and the foreign keys establish the links be-
`tween different files.
`
`system
`A database management
`(DBMS) is a software package. Its main func-
`tions are (1) to provide the facility to set up
`the database, (2) to retrieve and store source
`data (actual data in the database),
`(3)
`to
`retrieve and store the data about the struc-
`
`ture of the database (data dictionary), (4) to
`provide the facilities to enforce security
`rules, (5) to back up the database, and (6) to
`control the concurrent transactions so that
`
`one user's environment is protected from
`others.
`
`DATABASE DESIGN
`
`Before discussing automated database de-
`sign, it is essential to understand the mean-
`inglof database design and the processes
`involved. Basically, database design means
`identifying all the needed files, the fields of
`their records, and all candidate and foreign
`keys. Databases, like any "other software sys-
`tem, have their own software design life
`cycle. The process involved in the design of
`database systems are:
`=
`-'
`1. Analysis of the required informa—
`tion. In this phase, like any other software
`system, a precise definition of the problem at
`hand is established from interviews and ex- '
`
`amination of the organizational documents.
`Also in this phase, the description of the
`system constraints, requirements, queries,
`transactions, and needed reports are ex-
`pressed in short, concise sentences, usually
`
`I l I
`
`
` 4
`
`

`
`240
`
`DATABASE MANAGEMENT
`
`Teorey, J. T. 1990. Database modeling and
`desz'gn—The
`entity-relationship
`approach.
`San Mateo, Calif: Morgan Kaufmann.
`Welzer, T., I. Rozman, and]. Gyorkos. 1989.
`Automated normalization tool. Micropro-
`cessing and Microprogramming 25(1):375—
`80.
`
`Asad Khailany
`
`independence. That is, changes in the orga-
`nization of physical data and/or storage de-
`vice parameters are absorbed by the DBMS
`and, therefore, do not affect the user of the r
`database. If data were stored in a conven-
`
`tional file, changes in the record length, for
`example, would affect the program that ma-
`nipulates (or uses) those data.
`
`DATABASE MANAGEMENT
`
`As mass -storage prices fall and computers are
`used extensively throughout-businesses and
`other organizations, vast amounts of-*__valu-
`able information are piling up in electronic
`repositories. Finding ways to organize this
`information and to allow convenient access
`
`to it is steadily becoming more important.
`The emergence of advanced concepts based
`on artificial intelligence will make the stor~
`age and management of such vast amounts
`of infonnation even more critical.
`
`Software developers have come up with
`a variety of database management systems,
`which accept, organize, store, and retrieve
`information quickly and efficiently. A data-
`base is a collection of related data that con-
`
`tains information about an enterprise such as
`a university or an airline. Data include facts
`and figures that can be represented as num-
`bers, text strings, images, or voices stored in
`files on disk or other media. A database
`
`management system (DBMS) is a set of pro-
`grams (a software. package)
`that allows
`accessing and/or modification of the data-
`base. A major goal of the DBMS is to allow
`the user to deal with the data in abstract
`
`terms, rather than as the computer stores the
`data.
`
`Before databases were introduced, jisers
`had to write programs to manipulate data
`stored i.n files (conventional file systems en-
`vironment). Database management systems
`differ from the conventional file systems as
`follows.
`
`Data dependence. File systems exhibit data
`dependence, whereas a DBMS exhibits data
`
`In file systems, data may
`Data redundancy.
`. be duplicated. For example, the address of a
`customer may appear in a file representing
`the data for orders received and in a file
`
`representing orders shipped. An objective of
`a DBMS is to avoid this type of redundancy
`by placing common information in a single
`file and then, as users request the informa-
`tion, applying a certain set of operations on
`stored data to obtain the necessary informa-
`tion.
`
`there is no
`In file systems,
`Inconsistency.
`technique for checking whether various cop-
`ies of data are consistent. For example, if the
`' customer address changes,
`then the user
`might change that address in the order-
`received file and not in the order-shipped
`file; the customer. address therefore becomes
`inconsistent. It is the responsibility of the
`programmer tomanipulate the data so that
`they are consistent; if he or she. fails to do so,
`the program may produce incorrect results.
`In DBMSs, the database is always in a consis-
`tent state because changes to one piece of
`data are automatically absorbed throughout
`the entire system. Note that in databases, for
`efficiency purposes, the data might be dupli-
`cated; however,
`this redundancy is con-
`trolled.
`
`Lack of data integrity. Constraints may be
`imposed on certain data. For example, a
`customer can charge a sum greater than her
`or his allowed credit limit. In file systems, it is
`the responsibility of the user to determine if
`information entered violates the specific con-
`straints imposed, in this case, a credit limit.
`In DBMSS, however, constraints can be han-
`dled automatically. If the data entered into
`the system violate the constraints, the system
`rejects the data and/or warns the user about
`them.
`
`
` 5
`
`

`
`244
`
`DATABASE PROGRAMMING
`
`_[See also Data; Database Design, Auto-
`mated.]
`
`For Further Reading
`Date, C. J. 1990. An introduction to database
`systems, 5th ed., vol.
`I. Reading, Mass.:
`Addison-Wesley.
`Elmasri, R., and S. Navathe. 1989. Fundamen-
`tals of database systems. Redwood City,
`Calif: Benjamin Cummings.
`Korth, H., and A. Silberchatz. 1986. Database
`system concepts. New York: McGraw-Hill.
`Ozkarhan, E. 1990. Database management,
`concepts, design and practice. Englewood
`Cliffs, N.].: Prentice-Hall.
`Ullman, J. D. 1989. Principles of databases and
`knowIedge—base systems, vol.
`I. Rocltville,
`Md.: Computer Science Press.
`'
`
`Farshad Fotouhi
`
`DATABASE PROGRAMMING
`
`the years, programming languages
`Over
`have increasingly isolated the user from the
`inner workings of the computer and its oper-
`ating system; database programming partial-
`ly isolates the programmer from the details
`of data management by applying appropri-
`ate rules to the data handling, thus partially
`automating that part of the programming
`task.
`
`Databases are large, usually complex
`lists of facts and information; they usually
`contain regular arrangements of text and
`numbers, but modern databases, especially
`on personal computers, can contain video
`images (still or moving), sounds, large bodies
`of text, or combinations of all these elements.
`Many types of data fit best into-data-
`bases; today, most telephone directories, li-
`brary card catalogs, airline flight guides, and
`bibliographic references are kept in database
`forms, as are conventional databases con-
`taining accounting information, mailing lists,
`and the like.
`
`Although. you can still get many refer-
`
`ence works in paper, or "hard copy,” locat-
`ing the data m a large volume requires
`elaborate indices, which are both tedious
`and expensive to prepare and keep up—to-
`date. A database on a computer, on the other
`hand, can easily be re—indexed whenever the
`underlying data are changed; in fact,
`this
`tedious and complex task is automatically
`handled by the database management sys-
`tem whenever the data in the database are
`
`changed.
`The craft of data management dates
`back to Aristotle, the Greek philosopher, and
`the scheme of interlocking knowledge classi-
`fications he expounded in his Pbysica. Auto-
`mated data storage and retrieval first ap-
`peared in the 18805 when the Iacquard loom
`was developed; the loom could weave intri-
`cate patterns under the control of programs
`recorded on punched cards. The use of
`punched cards as a general-purpose data
`storage medium was further developed by
`Herman Hollerith. His card-sorting device, a
`precursor to the modem report generator,
`was used in the 1890 census.
`
`Over the years, data storage has come a
`long way, from the Hollerith cards to mag-
`netic tape (with the data usually still
`in
`Hollerith’s format) to massive modern data-
`bases stored on_ disk. Many modern data-
`bases are huge and complex, but the data
`input and inquiry programs make it relative-
`ly simple to use the data in them without a
`great deal of computer knowledge. When
`you call
`‘an airline's reservations agent, a
`special
`type of report generator tells the
`agent what seats are available on what flights
`and at what prices (see also AIRLINE RESERVA-
`non SYSTEMS).
`In discussing database programming, it
`can be helpful to distinguish between the
`database management system (DBMS) and
`the database programming language (DBPL).
`The DBMS" performs the task of manipulat-
`ing the data under the control of the DBPL.
`In many cases, however, the DBMS and the
`DBPL are integrated, and presented to the
`user or programmer as a command line or
`prompt at which one can type various com-
`mands to manipulate the chosen data.
`The permissable commands
`include
`both ad hoc commands,
`like LIST ALL
`
`
` 6
`
`

`
`712
`
`NETWORKS, LOCAL AREA
`
`tex service is an enhanced electronic mail
`
`service and is likely to become quite popular.
`The videotex service allows a person sitting
`at a terminal to interact with a remote data-
`
`base. Once the videotex system is in place, it
`would be possible to perform many common
`transactions, such as banking and reserva-
`tions, from a remote terminal.
`
`For Further Reading
`Bertsekas, D., and R. Gallager. 1987» Data
`networks. Englewood Cliffs, N.].: Prentice-
`Hall.
`
`Comer, D. 1988. lnternetworking with TCP/IP:
`Principles, protocols, and architecture. Engle—
`wood Cliffs, N.].: Prentice-Hall.
`_
`Davidson, I. 1988. An introduction to TCB/IP.
`New York: Springer-Verlag.
`Doll, D. R. 1980. Data communications: Facili-
`ties, networks, and system design. New York:
`Wiley.
`-
`Guruge, A. 1987. SNA: Theory and practice.
`Elmsford, N.Y.: Pergamon Press.
`I-Ialsall, F. 1988. Data communications, com-
`puter networks and OSI, 2nd ed. Reading,
`Mass.: Addison-Wesley.
`Henshall, 1., and S. Shaw. 1988. OSI ex-
`plained: End—to-end computer communication
`standards. New York: Wiley.
`Land, J. 1987. The integrated services digital
`network (ISBN). Manchester, Eng; The Na-
`tional Computing Centre.
`Martin, ]., and K. Chapman. 1987. SNA:
`IBM's
`networking
`solution. Englewood
`Cliffs, N.].: Prentice—Hall.
`Scientific American, Sept. 1991 (special issue:
`Communications, Computers and Net-
`works).
`_
`.
`Stallings, W. 1990a. Handbook of computer-
`communications standards, Vol. 1: The open
`systems interconnection (08!) model ‘and OSI—
`retated standards, 2nd ed. Carmel,
`Ind.:
`Howard W. Sams.
`.r
`
`. 1990b. Handbook of computer—com-
`munications standards, Vol. 2: Local area net-
`work standards, 2nd ed. Carmel, Ind.: How-
`ard W. Sams.
`
`. 1990c. Handbook of computer-com-
`munications standards. Vol. 3: The TCP/IP
`protocol suite, 2nd ed. Camel, Ind.: How-
`ard W. Sams.
`
`Tanenbaurn, A. 1988. Computer networks, 2nd
`ed. Englewood Cliffs, N.].: Prentice-Hall.
`
`S. P. Rana
`
`NETWORKS, LOCAL AREA
`
`See Local Area Networks;
`Networks, Computer
`
`NETWORKS, WIDE AREA
`
`See Networks, Computer;
`Wide Area Networks
`
`NONSTANDARD DATABASE SYSTEMS
`
`Database technology and the three common
`data models (i.e., hierarchical, network, and
`relational) were developed in response to the
`requirements of commercial data processing,
`which may be characterized by large vol-
`umes of homogeneous, record-oriented data.
`These models, however, are less effective
`when data objects vary in size and do not
`conform to any rigid structure. In addition,
`database languages based on these models
`have a limited expressive power and,
`in
`general, are not responsive to the complex
`requirements of sophisticated users. Recent-
`ly, a number of systems that extend the
`capabilities of ordinary databases have been
`developed. These systems can be identified
`as expert databases, temporal databases, spa-
`tial databases, deductive databases, object-
`oriented databases, and office in.forrnation
`systems (OISs). A short description of each
`system follows.
`
`‘
`
`EXPERT DATABASE SYSTEMS
`
`Conventional database systems are mainly
`concerned with efficient storage and retrieval
`of data. Generally, all data must be explicitly
`
`
` 7
`
`

`
`
`
`NONSTANDARD DATABASE SYSTEMS
`
`713
`
`stored, and thereis no mechanism for deriv-
`ing new facts from the existing information.
`In expert systems, which are often idealized
`as systems that can imitate the expertise of a
`human being, the emphasis is largely on
`deduction of new facts, and they are not
`confined to the stored data. Expert database
`systems attempt to integrate the capabil-
`ities of expert systems and database systems
`into one coherent’ system. These systems pro-
`vide, on -the one hand, constructs for the re-
`presentation of knowledge in the form of
`rules or frames along with capabilities for
`search and inferencing, and on the other
`hand, the ability to efficiently and reliably
`store, retrieve, and update large volumes
`of data.
`
`The integration of databases and expert
`systems may be achieved in several ways.
`
`0 A database system may be enhanced to
`include rules and inferencing power. This
`technique is suitable for a‘ large database
`that has been in operation for a long time.
`The knowledge base and the accompany-
`ing inference engine are similar to other
`application programs that
`receive data
`from the database. In certain types of ex-
`pert databases, called active databases, the
`system has triggers (or rules that when
`executed invoke a transition) and transi-
`tion constraints. Some ‘rules are tied to
`constraints; and once a constraint is violat-
`ed, a rule or a collection of rules is execut-
`ed. Some of these rules may be used for
`user notification, in which case they are
`called alerters.
`'
`'
`
`- Alternatively, an expert system may be
`extended with database capabilities and
`transparent access to data. In contrast to
`the previous method, the underlying data-
`base system in this metl1od has no autono-
`my because it is generally used in conjunc-
`tion with the expert system.
`- A third method requires interface of an
`expert system and a database system. In
`this cooperative mode, the expert system,
`which knows the structure and the schema
`of the database, formulates its queries ac-
`cording to the modus operandi of the
`database. In return, the database system
`presents its answers in a format readily
`
`usable by the expert system. This scheme is
`advantageous because the two systems
`exist and operate independently of each
`other.
`
`0 A fourth method requires development of
`expert database systems in an integrated
`framework that allows both database capa-
`bilities and inferencing power. In this ap-
`proach, one unified system executes both
`functions. (See the section on deductive
`databases below.)
`
`IBM's STARBURST project extends Struc-
`tured Query Language (SQL) and aims to
`support the increasing demands of a variety
`of applications including expert
`systems
`(Haas et al. 1988). KEEConnection, on the
`other hand, is an example of efforts to extend
`expert systems with database capabilities. It
`enhances the expert system KEE with data-
`base functions (KEE 1988).
`
`TEMPORAL DATABASE MANAGEMENT
`SYSTEMS
`
`Current database systems do not maintain a
`history of attribute values. In effect, each
`update destroys the old fact. In certain appli-
`cations, keeping track of all previous infor-
`mation is important (e.g., maintaining histo-
`ries of previous illnesses and medications in
`a hospital's patient database). To meet this
`need,
`temporal databases were designed
`with the aims of incorporating time in data-
`base systems and allowing multiple versions
`of data items to be stored in and retrieved
`from the database. Generally, temporal data-
`bases separate time-dependent data from
`time-independent data and provide some
`sort of time-keeping scheme for their.man-
`agement. Attribute time stamping is a simple
`method for managing temporal data. Each
`new attribute value is augmented with a
`timestamp that records the time of the up-
`date and thus distinguishes the current value
`of an attribute from its previous versions. By
`assigning a timestamp to each value, the
`database system can process queries that
`involve temporal relationships, such as ”be-
`fore," "after,” and ”dur.ir1g” (see Clifford
`and Tansel 1985 for more details).
`
`
` 8
`
`

`
`714
`
`NONSTANDARD DATABASE SYSTEMS
`
`SPATIAL DATABASES
`
`F _ _ _ _ - — _ _ "-1
`
`As temporal databases incorporate time into
`the system, spatial databases extend the ordi-
`nary database systems by modeling the space
`dimension. The word space is used loosely to
`capture such entities as lines, drawings, and
`graphs and such spatial relationships as
`proximity and boundary. There are many
`applications for spatial databases, including
`computer-aided design and manufacturing,
`geographic information systems, and geo-
`metric modeling and design.
`Spatial databases must store both spatial
`and nonspatial information. The former is
`the representation of drawings, regions, and
`lines, whereas the latter consists of alphanu-
`meric values as in conventional systems.
`Specific operations in a spatial database de-
`pend on the type of information it contains.
`For example, in a geographic database sys-
`tem in which maps consisting of several
`regions are stored, the following operations
`(among many others) are essential: union,
`projection, fusion, selection, and superposi-
`tion. Figures 1 through 5 illustrate these
`operations.
`For further reading, see Buchmann et al.
`(1989) and Kastuti et al. (1989).
`
`DEDUCTIVE DATABASES
`
`The emergence of PROLOG in the mid-
`1970s generated interest in investigating a
`more active role for logic in the design of
`database query languages and database
`processing. Deductive databases are the con-
`fluence of ideas from logic programming and
`relational databases. Thus, as in PROLOG,
`data and knowledge are represented as I-Iorn
`clauses (or rules) of the form
`
`A:-B1&B2&...8:-B11,
`
`. and B1: are predicates.
`.
`where A, B1, B2, .
`A is called the head of the clause, and B1 6:
`B2 8:...& Br:
`is called the body or the
`condition of the clause. The condition part of
`a clause may be empty, in which case we call
`it a fact. A database is essentially a collection
`of Horn clauses of the above form. In deduc-
`
`tive databases, however, most of the Horn
`clauses have no conditions (i.e., they contain
`mainly facts.) Queries to the database are
`formulated as they are in PROLOG.
`
`I:
`
`c
`
`FIGURE 1. Union of two maps: (a) map m1. (b) map
`m2, (c) the union of m1 and m2.
`
`region 3
`
`region 4
`
`region 1
`
`'
`
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I _ _ _ _ _ # _ _ _ _ J
`I‘ " ‘ - - ‘ - _ " ‘ _ l
`I
`I
`I
`I
`I
`I
`
`
`
`:
`
`region2
`
`II
`
`region 3
`
`I
`I
`I
`I
`I
`I
`I
`I
`I ________ _ _ .1
`
`
` 9