Secure query processing using AI techniques - UT Dallas

SECURE QUERY PROCESSING USING AI TECHNIQUES

MB.Thuraisingh Honeywell Coqmate Systems Development Division Golden Valley, MN 55427

W.T. Tsai

-en'

TJ? Keefe

of Computer Science UIuversity of Minnesota Minneapolis, M N 55455

-

Department of Computer Science university of M i n n m Minneapdis, MN 55455

and co-workers have focussed their attention on the foundations of the inference problem in database security. They have since established a general framework within which the inference problem in MLSDBMS can be overcomc?*8In contrast,T h d i g h a m at Honeywell has been directing her efforts at particular aspects of the inference prob1em.9JO She has designed an architecture foc a MLSDBMS which augments a DBMS with infexence engine and then investigated a query w i n g strategy which handles the inference problem arising from logical inference. Thuraisingham's results have been illustrated mainly with examples. Efficient techniques for secure query procesSing are yet to be formulated.

Abstract This paper describes the use of AI techniques for query processing in a multilevel secure database management system. The techniques ensure that a query is modified in such a way that if the modified query is posed, then the response generated will not violate security requirements. These techniques also handle constraints which classify data by content and context, and also constraints which classify data which depends on the classificationS of otha data. Zndex Terms- Multilevel security, Multilevel secure database management systems, Knowledgebased system, Security policy

This paper will discuss the problems encountered in designing Multilevel Secure Database Management Systems, (MLSDBMS) and propose solutions utilizing AI techniques for some of these problems. We will explore the suitability of techniques used in AI applications for secure database query retrieval. More precisely we discuss the use of the relational model and logic for re-ting security relevant knowledge and we propose two graph factoring methods. one based on rewrite rules and the other based on graph factoring. Such techniques will not only overcome certain security violations in DBMS but will also eventually lead towad security in knowledge-based systems.

SYSTEMS Multilevel Secure Database Management Systems, (MLSDBMS) evolved from the successful multilevel secure computing systems.1 ~t addresses the natural expectation that users cleared at different levels share and access data at varying sensitivities. However present-day DBMS are not built with adequate controls and mechanisms to ensure that users are allowed to access only the data to which they have clearance. Thus an MLS/DBMS is different from a conventional DBMS in at least the following ways:

The organization of this paper is as follows: In Section 2, we will describesome previously proposed techniques for retrieving data from a MLSDBMS and discuss their limitations. In Section 3 we propose new techniques for query processing in MLSDBMS augmented with inference engines which overcome some of these limitations. Finally in Section 4, we conclude with future considerations.

1. every data item has associated with it one of several classification levels that may need to change with time,

2. a user's access to data must be controlled based upon the user's authorization with respect to these data classifications. Providing an MLSDBMS on current secure computing systems presents a new set of problems. The most obvious of these problems is that the granularity of classification in a DBMS is generally finer than a file and may be as fine as a single data element in a file. Another problem that is unique to databases is the necessity to classify data based upon context, time, and aggregation. Furthermore, DBMSs are also vulnerable to inference aaacks where a uset infers unauthorizeddata from the knowledge that he has accumulated.

Query modification techniques have been used extensively in the past to transform queries into a more appropriate format for a particular application. For example, queries against views have been transformed into quaies against base relations.'l In deductive databases. queries against virtual relations have been transformed into queries against base rehtions.12 Query modification has been used in a discretionary access control me~2hanism.l~ A variation of this technique was proposed for mandatory access control through query modification6 In this section we will describe this query modification mechanism and then state some of its drawbacks. In essence, the user's query is modified by applying the relevant security constraints for the particular query in such a way that if the modified query is posed then the response generated by the DBMS will not result in any security violation. Before illushating this technique with examples, we will fmt give an exposition on security COnStraints.

The Air Force Summer Study of 1982: proposed various designs for Multilevel Secure Relational Database Management Systems, (MLSRDBMS). One. a near term set of requirements inunporathg offthe-shelf concepts, and two a longer term set of requirements which include content, context, dynamic classifications and solutions to the inference problem. Two groups have taken up the challenge of seeking a long term solution with the purpose of incoyrating features of multilevel security to prevent security violations. .4.5*6 What has since become apparent is that present strategies employed in MLS/RDBMS are neither wholly sufficient nor efficient in processing queries while ensuring that users do not acquire information to which they are not autho*ed. To overcome the k k of suitable techniques. the database ~ * applying ~~ AI security researchers at SR17s8 and H ~ n e y w e l l are techniques to solve problems in database security. At SRI,Morgenstern

Security constraints assign classification levels to all data in the database6. They provide a basis for a versatile, powerful classification policy because any subset of data can be specified and assigned a level statically or dynamically. Simple constraints provide for the classification of the entire database, as well as the classification by relation and by attribute. Constraints that classify by content provide

56 1

TH0212-l/88/oooO/0561$01.00 0 1988 E E E

Authorized licensed use limited to: Univ of Texas at Dallas. Downloaded on April 16,2010 at 19:06:43 UTC from IEEE Xplore. Restrictions apply.

the mechanism for classification by tuple and by element. Contextbased constraints classify relationships between data. In addition, the results of applying functions to an attribute or a subset of an attribute, such as sum, average, and count can be assigned different classification levels than the underlying data. Finally, the classification levels of the data can change dynamically based upon changes in time, content, or context.

database management systems are not sufficient to resolve the major compromise to security due to the inference of unauthorized information from the information that users can legitimately acquire. To overcome such attacks, the information on all responses that have been released must be maintained. Furthermore,for each additional query that is posed some efficient computation technique is required to see if the response generated combined with the previous responses will cause a breach in SeCmity.

A constraint consists of data specification and a classification. The data specification defines any subset of the database using relational algebra and the classification defines the classification level of this subset. For example, consider a database which consists of a relation EMP(SOCSEC#,NAME,SALARY, DEFT#) with SOC-SEC# as the key. The content-based constraint which classifies all names who eam more than lOOK as secret is expressed as:

In the next section we will explore the representation of constraints, representation of history of released information and their manipulation to process queries securely.

FOR -C ES In this section we describe strategies for query processing in an MLS/DBMS. The underlying mechanism used in all strategiesis "query modification". It should be noted however, that even if the query is modified comxtly, the response generated may still violate security if the DBMS contains a Trojan horse (or hostile code) which will signal information downward in level. To ensure that no Trojan horse exists, specific portions of the code have to be verified. In this paper we do not consider the verifcation issue. Instead we concentrate on different strategies that can be used to modify the query.

LEVEL(PROJECT[NAMEl(SELECT[SALARY> loOK1 EMP)) = SECRET and the context-based constraint which classifies all names and salaries taken together is expressedas:

LEVEL(F'ROJECT[NAME.SALARY] EMF') = SECRET The simple constraint which classifies all names and salaries in EMP taken individuallyas secret is expressed as:

There are two important concerns related to a strategy for secure query processing. First is the representation of the knowledge required for processing the query, this includes the constraints, environmental knowledge, and teal-world knowledge. Second is the effiient methods of manipulating this knowledge. For example methods for finding constraints relevant to a given query or methods for constructing the modified query. The next two sections deal with these issues. Section 3.1 discusses knowledge representation and Section 3.2 deals with methods for modifying queries using one of the knowledge

LEVEL(PROJECT[NAME]EMP) = SECRET LEVEL(PROJECT[SALARYI EMF') = SECRET

It is important to note that simple and content-based constraints can be applied to data as it is actually stored in the database, while context constraints can be applied in the computation of the result which is to be output in response to a user's query. For example, if the contentbased constraint which classifies all names who earn more than lOOK as secret is enforced, the secret names are stored in a secret file and the unclassified names are stored in an unclassifd file. If the context-kied constraint names and salaries taken together is secret is enforced. the names and salaries are stored in unclassified files and the constraint is applied only when the response is generated.

representations.

There is basically threekinds of knowledge which must be represented. First and most important is security constraints, including simple, content, and context types. Second is environmental information concerning what data has been released at what level. Finally there is real-world knowledge describing virtual relations and miscellaneous facts. These representation problems are discussed in the following

The security constraints are used in evaluating queries as follows: Suppose an unclassified user wants to retrieve all the names from the relation EMF' and the content-basedconstraint which classifies all names who eam more than lOOK is enforced. Then the query is modified to retrieve all names where the corresponding salaries are less rhan or equal to loOK. This modified query is then evaluated and all the unclassified names will be retrieved. The formal description of this query modification algorithm is stated in6.

WtiOllS.

The organization of this section is as follows: In Section 3.1.1. we descni how a standard relational MLSDBMS p " e s queries. Here we assume that the security constraints are represented by the relational model and then point out the inability of this model to handle inference. In Section 3.1.2 we will describe an MLSDBMS augmented with an Inference Engine and demonstrate the suitability of logic for representingthe lE4zsay knowledge.

Although the query modification algorithm modifies the query correctly. it does not specify how to extract the relevant constraints. In some cases, a relation may have numerous constraints enforced on it. In addition, constraintsenforced on JOIN opedons are rather complex. An example of a constraint enforced on a JOIN operation is as follows: Consider the relations:

3 . 1 . 1 Most existing relational database management systems ais0 use the relational model to represent metadata. 'Ihereforc, we will fmt examine the suitability of such a model for the representation of meta-data for a MLSDBMS. The meta-data of a MLS/DBMS will include the external schemas which describe the views, the conceptual schemas which describe the relations and the attributes, the internal schemas which describe the physical files, the security consmints and the integrity constraints. We will illustrate our design of the data dictionary which contains the mea-data with an example.

EMF'(SOC-SEC#,NAME, SALARY, DER#)

DEPT@EF'T#,PROJECT,DNAME, MGR) SOC-SEC# is the key of EMP and DEFT# as the key of DEFT. We enforce the constraint which classifies all names in EMP who work in a particular project say "STARS" in DEFT as secret. This constraint necessitates the JOIN of the relations EMP and DEPT. Such constraints necessitatean efficient search procedure to extract the relevant consuaints for a query.

Suppose the dataconsists of the relation EMF' and DEPT described earlier. Let the following security constraints be enforced:

Another drawback with the query modification algorithm is that it takes into consideration only the response to the current query. It does not check the history information as to whether the response to be generated taken together with previously released responses may lead to security violations. In other words, the algorithm does not handle inference attacks. This is so because techniques employed by standard relational

562

Authorized licensed use limited to: Univ of Texas at Dallas. Downloaded on April 16,2010 at 19:06:43 UTC from IEEE Xplore. Restrictions apply.

in our model. Although it is possible to represent such real-world information using the reiational model, the manipulation of such information is quite comdex. Another difficulty is encountered with the relational model in representing constraints when the level of one attribute depends on the level of another. In the previous example, suppose we have another constraint which classifies salary to be secret only if the department number in EMP is secret. If an unclassified user wants to retrieve the salaries. then the query is first modified to retrieve all salaries where the predicate DEPARTMENT-UNCLASSIFIED is true. But this modified query cannot yet be evaluated against the relational database. The tables have to be searched again to get all the constraints which classify the department number as secret to provide a definition for the DEPARTMENTJNCLASSIFIEDpredicate.

Rname Emp

Dept

I

Arity

4 4

Cardinality 0 0

Primary Key

Foreim Key DepH NULL-

SS# Depat

Name

Emu Emp Deut Dept Dept Dept

The third difficulty is inferencing over time. Users can accumulate various sets of information retrieved over many sessions and infer unauthorized information. This scenario can be described with a simple example. Suppose some information R is released at a level L (i.e. to users at level L). This information is also available to a l l users at levels L1 2 L. However, a security violation occurs if users at level L1 2 L can combine R with the information (or history) I(L.1) already available to them and infer some information at a level L2 > L1. This example shows that not only should information be maintained regarding the constraints. information should be maintained on the access history of the data for each security level. In addition, users may have other sources of information apart from the database. Such real world information should also be taken into account.

Salary

I

The relational model is capable of storing the necessary types of security information for the examples above and algorithms could be designed to manipulate the information in the necessary ways. If the relational model is viewed as an abstract data type, as data and operations defied on it, the problems become apparent. The types of operations naturally defmed for the relationaldata model is the relational algebra perhaps with some extensions. It is clearly not practical to do the kinds of inference necessary to modify queries using these types of operators. Theaefore if the knowledge repsentation problem is viewed in terms of abstract data types, clearly relational algebra is inappropriate. This is evidenced by the complex algorithms necessary to carry out even simple query modifications.

Dept#

Project Dname Mgr Tahle 4'

c1

text1 teXI2 text3 text4 text5

c2

I Rname Emp v1 Dept

c3 c4 c5 Cname c1 c3 c5

Target Name Name Pro*t

Condition Sakuy>lOOK Project="Stars" NULL

If the database security problem is simply stated using logic, then a knowledge representation that supports inference seems an appropriate choice. In the ensuing sections we will describe a relational database management system augmented with an inference engine which not only facilitates the representation and manipulation of constraints for query modification but also lays the foundation for solving the inference problem arising from logical inferences.

I

U.2 L O G I C A T I O N - T h e

Level Secret Secret Secret-

desire to integrate

Table 6

NULL

De

*

technology, amfcial intelligence technology, and logic programming technology resulted in the investigation of extending database systems to provide them with the functionality of expert systems, thus creating knowledge-based systems.14 A solution that has been proposed to extend the power and capability of database management systems is to augment a database with a knowledge base which consists of all information for which the relational model is not a suitable representation. and a processing system called the inference engine separate from the DBMS to process the information in the knowledge base.15 A high level architecture of an augmented DBMS is shown in Figure 1. Since standard relational databases are not powerful enough to overcome the inference problem, the augmented database approach can be taken to design an MLSPBMS. The database consists of only the information that can be manipulated easily by the relational DBMS. The knowledge base consists of all the security constraints, integrity constraints, and the real-world information. Since the constraints can be expressed as d e s , logic is an appFopriatecandidate for modelling the knowledge base.

secret secret secret

The relational model has three major weaknesses as a means for knowledge representation for secure query processing. First, suppose an unclassified user wants to obtain all names. Then the Tables 5 and 6 will have to be searched for all the relevant constraints. The relevant constraints in this case are. C1, C2 and C3. Furthermore Cl and C3 are directly relevant and the query will be f i t modified to retrieve all names where the salary is less than lOOK and who do not work in the project STARS.The constraint C2 becomes directly relevant only if the salaries have been released earlier. But this information is not represented

563

Authorized licensed use limited to: Univ of Texas at Dallas. Downloaded on April 16,2010 at 19:06:43 UTC from IEEE Xplore. Restrictions apply.

s 1

where RELEME(X,L) implies X has been releasedat level L.

Suppose an unclassifkd user wants to retrieve all names from E m . Then t h e g e d techniquedtomodify lhequey: (Y:Ehrlp(x,Y&Wj)

is as follows The knowledge base will be searched for a l l rules which will ciasslfy the names in EMF'. These d e s are. Rim, and R7. The conditions in these rules will be negated and the resulting 9 u ~ is y

Engine

t

t

( YEMP(X,Y,Z,W) A Z S lOOK A DF,F'T(P.Q,R,S) A-(P=W QSTARS) A

/_I

A

-,RELEASE(Z,SECRET))

Knowledge

Figure 1

- Relational

This query cannot be evaluated still as RELEASE is not a base relation. Therefore the knowledgebase will be seachedto see if the salaries have been released. Since the salaries have not yet been released, -RELEASE(Z,UNCLASSIFIED) is TRUE. Therefore the query that will be evaluated is:

DBMS Augmented with an Inference Engine

(Y:EMP(X,Y,Z,W)

In addition to the ease of expression and manipulation of constraints expressed in logic, another advantage of using logic is that logical deduction of formulas fits in naturally with the deduction of information that may lead to the violation of security by inference. Consequently a definition of "violation of security by inference" can be formulated as follows:

Z lOOK which classified the name. The contextbased constraint C2 classifies names and salaries taken together as secret. The two edges originating from SALARY0 and NAME(Y) meet at LEVEL(Y2, Secret). There is no condition attached to this constraint and therefore the node LEVEL(YZ. Secret) does not have any edges originating from it. If on the other hand the names and salaries taken together are secret only in the department with DEPT# = "DI". then

Figure 7 shows how the constraints C1 and C2 are represented. EMF'(X,YZ,W) is the label of a node with in-degree 0. Since EMP has four attributes, there are four edges which originate at this node. The nodes at the end of these edges specify the correspondingamibute. For

568

Authorized licensed use limited to: Univ of Texas at Dallas. Downloaded on April 16,2010 at 19:06:43 UTC from IEEE Xplore. Restrictions apply.

there will be an m w from LEVEL(YZ,Secret) to the condition W = "Dl". The node labelled with this condition will be the head of the edge whose tail is DEE*IW(W).

incomparable to the unclassified level. In this example the node found will be LEVEL(Y,SECRET). Then all edges which originate from this node will be m v d . The two nodes that will specify the conditions to

When an unclassified user wants to retrieve the names and salaries together, the search is started at the node EMPO(.YZ.W) for the atuibutes NAME and SALARY. The purpose of this =h is to fmd a node which classifies names and salaries taken together at any level greater than or incomparable to the unclassified level. In this search, first the nodes NAME@) and SALARY(Z) will be visited and subsequently the node LEVELW.SECRET) will be reached. Since the namesand salaries taken tog& are secret and their is no edge from the node LEVEL(YZ,SECRET), no query will be posed. If a secret user wants to retrieve the names and salaries together, the search will be for a node which classifies names and salaries taken together at a level greater than or incomparable to the secret level. Since there is no node in the graph with this property, the query will not be modified. S u p an unclassied user wants to reaieve the names only. Then the search will be for a node which classifies names only at a level wter than or incomparable to the unclassified level. The node LEVEL(Y.SECRET) is such a node. Then all the nodes pointed to by edges emanating from LEVEL(Y,SECRET) will be examined and the conditions in these nodes will be negated to modify the query. Therefore the resultant queay will be to retrieve all names whose salaries are less than o r e q d to loOK. If a secret user wants to retrieveall the names, then the =h will be for a node which classifies all names at a level greater than or incomparable to the secret level. Since there is no such node. the query will not be modified

classify the names are Z > lOOK and P=W A +STARS. Then these conditions will be negated and the query will be modifd to retrieve all names where the salary is less than or equal to 100 Kand whodo not work in STARS.

--

.

p Now let us examine how multiple queries can be handled. Because of the constraint CZ, the names should not be released to an unclassified user if the salaries have been released earlier and vice versa. In other words the context-based constraint C2 will automatically enforce the two constraints R8 and R9. That is the names are secret if the salaries have been released and the salaries are secret if the names have been released. The additio~l information that has to be incorporated into Figure 7 to enforce the constraints R8 and R9 are shown in Figure 9. In this figure we have two more nodes. One of these nodes is labelled RELEASE(Y.Unclassified) which implies that names are released and the other node is labelled RELEASE(z,Unclassied) which implies that salaries are deased. Because of the constraint R8 there will be an edge from LEVEL(Y,SECRET) to the condition RELEASE(Z,Unclassified) and the constraint R9 will be enforced by the edge from LEVEL(zSECRJ2T) to the condition RELEASE(Y.Unclassified). Now if an unclassified user wants to obtain the salaries after he has obtained the names, then a search will be made for a node which classifies salaries at a level greater than or incomparable to the unclassified level. The node that will be found is LEVEL(Z,SECRET). The condition that is pointed by this node is RELEASE(Y,Unclassified). Therefore the query will be modified to retrieve all salaries where the names have not been released. But this query still cannot be evaluated because the predicat+ RELEASE is a virtual predicate. Therefore a search has to be made as to whether names have been released. In order to do this we need another graph to represent the real world information. This is shown in Figure 10. As soon as the names are released at the unclassitied level form the previous query, this information has to be into the real world information. Therefore the N A M E 0 in Figure 9 has an edge whose tail is RELEASEW. Since the names are already released at the unclaosified level, the negation of the condition RELEASE0 is false. Therefore the query is modified to the null query andnoqwy willbe posed to retrieve the salaries.

.

In the above discussion, we have assumed that there are no constraints on derived relations such as the constraint C3, nor can we handle multiple queries such as retrieving the names fmt and then the salaries. We will now examine each of these cases. First suppose the constraint C3 is enforced in addition to the constraints C1 and CZ. " Ithe additional information that has to be incorporated into Figure 7 is shown in Figure 8. To express the constraint C3,first a join operation has to be performed between EMP and DEFT over the attribute DEFT#. Therefore we have another node DEFT(P.Q,RS) which has in-degree 0 and with four edges originating from it to represent its four attributes. Since the join is OVQ DEFT#, there isan edge from thenode DlPW(W) which cornspondsto the relation EMP,there is an edge from DEFT#(P) which cOmSpOndS to relation DEFT, and there is an edge from PROJECT(Q) which all meet at the node P=W A Q=STARS. Since the namcs in project "STARS"are secret, there is an edge from LEVEL(Y,SECRET) to the node P=W A *STARS. The query is processed in a manner similar to before. For example, if an unclassified user wants to retrieve all names, a search is made for a node which classifies all names at a level greater than or

Figure 8

- Constraints on Joins

569

Authorized licensed use limited to: Univ of Texas at Dallas. Downloaded on April 16,2010 at 19:06:43 UTC from IEEE Xplore. Restrictions apply.

1. L. J. Fraim, "Scomp: A Solution to the Multilevel Security Problem", IEEE Computer, Vol. 16, #7, July 1983. 2.

"Multilevel Data Management Security", Committee on Multilevel Data Management Security, Air Force Studies Bed. Commission on Engineering and Technical Systems, National Research Council, National Academy Press, Washington D. C., 1983.

S.K. Aki, M. Morgenstem. P.G.Neumann. R.R. Schell, and M. Heckman, "Views for Multilevel Database Security", in Proceedings of the 1986 Symposium on Security and Privacy, April 1986.

3. DE. Denning,

Figure 9

- Representing

Context-based Constraints

4.

D.E. Denning, T.F. Lunt, R.R. Schell, M. Heckman. and W. Shockley, "A Multilevel Relational Data Model", in Proceedingsof the 1987 Symposium on Security and Privacy, April 1987.

5. B.B. Dillaway and J.T. Haigh, "A Practical Design for Multilevel

Security in Secure Database Management Systems", Aerospace Secwiry Conference, Decembex 1986. 6. P.A. Dwyer, G.D. Jelatis, and M.B. Thuraisingham, "Multilevel

Security in Database Management Systems", Computers di Securiry Journal,Vol. 6, #3. June 1987.

6

M. Morgenstern. "Military Database Technology Study: AI Techniques for Security and Reliability", SRI Report, August 1986.

7. D.E. Denning, and

Release(Y,Uncllssified)

Figure 10

-

Representing Real World Information

8. M. Magenstem, "Securityand Inference in Multilevel Database and Knowledge-BaseSystems". ACM SIGMOD Conference, 1987.

The mechanism described here is also applicable when the level of a piece of data depends on the level of another. Suppose the names in EMF are secret only if the salaries are secret. Then the node which is labelled LEVEL(Y,SECRET) has an arrow to the node labelled LEVEL(Z,SECRET). The query is then modified to retrieve all names where the salary is not secret. This query cannot be evaluated still as it contains a virtual relation. The graph is searched again for all the conditions which make salary in EMP secret. This is quite simple as all one has to do is to follow all the edges which originate at LEVEL(2,SECRET).

9.

M.B. Thuraisingham. "Security Checking in Relational Database Management Systems Augmented with Inference Engines", Compurers & Securiry Journal,Vol. 6. u6.1987.

10. M.B. Thuraisingham.

"Toward the Design of a Secure DaWKnowledge-Base ManagementSystem". Submitted to Data & Knowledge Engineehg Journal.

11. M. Stonebraker, "Implementation of Integrity Constraints and

Views by Query Modification", in Proceedings of the 1975 ACM SIGMOD Conference on the Management of Data, San Jose, Cal., . May 1975, p ~65-78. In this paper we have described techniques for query processing in a MLSDBMS. We have described how logic can be used to represent the knowledge required for query msformation, and described twa query transformation methods, one using rewrite rules and the other graph factoring. The proposed techniques ensure that a query is modified in such a way that if the modified query is posed, the response generated will not violate the security requirements.

12. C.L. Chang, "Deduce 2 Further Investigations of Deduction in Relational Data Bases" in Logic and Data Bases, Heme Gallaire and Jack Minker. Ed., New York, 1978. 13. M. Stonebraker and E. Wong, "Access Conaol in a Relational

Database Management System by Query Modification", in Proceedings of the I974 ACM National Conference, San Diego, Cal.. November 1974, p ~ 180-187. .

There are many issues that still remain to be investigated. Most importantly, the performance of the techniques have to be analyzed. Other issues include the termination problem of rewrite rules for recursive queries, and whether the techniques proposed here will handle all types of logical inferences. Finally we need to perform a formal evaluation of the various strategies that have been proposed and also explore the feasibility of using other strategies used in logic programming systems. Nevertheless, we believe that the techniques proposed in this paper are the first step towards examining implementable solutions to query processing in an MLSDBMS and will also form the basis of security in knowledge-based management systems.

14. F. Bancilhon and R. Ramalaishnan. "An Amateur's Introduction to

Recursive Processing Simkgies". Proceedings of ACM Sigmod '86, pp. 16-52. 15. M. Brodie, J. Mylopoulos, J. Schmidt, On Conceptual Modeling,

Perspectives from Artificial Intelligence, Databases, and Programming Languages, Springer-Verlag,1984. 16. W.A. Woods, "Knowledge Base Retrieval", in Knowledge Base

Management Systems, M. Brodie, and J. Mylopoulos, Ed., Springer-Verlag. 1986.

570

Authorized licensed use limited to: Univ of Texas at Dallas. Downloaded on April 16,2010 at 19:06:43 UTC from IEEE Xplore. Restrictions apply.