A Design Methodology for Databases with Uncertain Data*

Transcription

1 A Design Methodology for Databases with Uncertain Data* Nauman A. Chaudhry, James R. Moyne, Elke A. Rundensteiner The University of Michigan, Dept. of Electrical Engineering & Computer Science, Ann Arbor, MI chaudhry, moyne, Many real world systems and applications require information management components that provide support for managing imprecise data. There have thus been several proposals for extending relational database systems in order to represent as well as query such imprecise data. Little work, however, has been done in modeling uncertainty at the conceptual schema level and in developing design methodologies for developing fuzzy relational databases (FRDBs). To fill this gap, a design methodology for FRDBs is proposed. This methodology contains extensions for representing the imprecision of data in the Entity-Relationship (ER) data model, and a set of steps for the derivation of a FRDB from this extended ER model. As a case study this methodology has been applied to the design of a control database for semiconductor manufacturing. Keywords: Uncertainty modeling, fuzzy databases, supervisory control, ER design methodology. 1.0 Introduction Many real world applications, e.g. genome, geophysical and biological systems, must deal with imprecise or vague data. For such systems, we need information management systems that provide support for managing this imprecise data. Significant work has been done in incorporating uncertainty management in relational databases (RDBs) using fuzzy set theory [BuP82], [PrT84], [RuB92], [Uma82], [ZeK85], but little has been done in modeling fuzziness in conceptual data models. There has also been little progress in developing design methodologies for implementing fuzzy RDBs. In general, a database is designed by first developing a high-level conceptual model, such as an ER model. We support this database design process by extending the representation of imprecision at the conceptual data model level. Next the conceptual model needs to be mapped to an actual implementation, typically using a relational database system. To address this issue, we propose a design methodology for implementing fuzzy relational databases. This methodology, based on the ER design methodology of Teorey et. al. [TYF86], prescribes a sequence of steps to implement a fuzzy relational database from this extended fuzzy ER model. In this paper, we demonstrate the utility of our methods by applying our methodology to a system which must cope with imprecise information. This system is a run-to-run (R2R) process control 1 framework developed for supervisory control of VLSI manufacturing processes [CTM93]. At the heart of this framework is a generic cell controller implementation that serves to support the R2R control algorithm [MoM92]. The cell controller, explained in greater detail in Section 5, responds to messages received from external controllers or users by matching these incoming messages to entries in a database. This R2R database contains the information needed to handle the incoming messages. As will be discussed later, a crisp (i.e. a non-fuzzy) data model proves inadequate for providing support for some R2R control tasks. Thus fuzzification can be usefully employed to develop a database that is better suited for R2R control. We identify several aspects of the database that need to be extended to handle imprecision. We then use the proposed fuzzy conceptual design methodology to carry out these fuzzifications to the R2R control database. The resulting fuzzy control database has been successfully integrated into an actual R2R framework. *This paper will be presented at the 7th International Working Conference on Scientific and Statistical Database Management, Charlottesville, Virginia, September 28-30, Run-to-run process control is a form of sequential (discrete) control that utilizes data from the last run (i.e., process step) or a series of previous runs to derive a better model for the next run. A Design Methodology for Databases with Uncertain Data* 1

2 Section 2 of this paper describes related work. Section 3 contains background material. Section 4 contains a description of extensions to the ER modeling approach we propose to capture fuzzification at the conceptual level. In Section 5, the original R2R database implementation and resulting problems are described. The resulting fuzzifications applied to the database to address these problems are explained. Section 6 concludes this paper with a summary of results and an outline of future research. 2.0 Related Work Most previous research on fuzzy databases has focused on the relational model. The fuzzy relational database model enhances the relational model by modeling imprecision in data and/or query [BuP82], [Uma82], [PrT84], [ZeK85]. This is achieved by using the concepts of fuzzy sets and possibility distribution 1. To express imprecision of a data value, the set of possible attribute values allowed in the relational representation is extended from simple scalars or numbers to sets of scalars or numbers, possibilistic distributions, and fuzzy membership values. Fuzzy relational database (FRDB) models put forward by different authors allow different combinations of some or all of the above data values [UnF92]. While many efforts have been directed towards extending the relational data model, not much work has been done in either extending the higher-level conceptual data models or the design methodologies to incorporate fuzziness. The only effort that we are aware of in the area of fuzzy ER modeling is by Zvieli and Chen [ZvC86]. They consider fuzziness at three levels. The first level models fuzziness of an object (entity or relationship) relating to its presence in the model. This type of fuzziness is transient in that it may exist only during the modeling or modification stage of the database life-cycle. The second level relates to modeling the fuzziness of occurrence of specific entity instances or relationships in the corresponding entity/relationship set. In the third level attributes of a specific entity/relationship may be fuzzy. Levels two and three are expressed in the ER model of [ZvC86] by attaching the letter f with the fuzzy entity/relationship/ attribute. In [FSI91], the authors use a graph-oriented schema for modeling a fuzzy database loosely based on the model of [ZeK85]. They map to a quasi-semantic data model rather than a relational model. An extended semantic data model to capture fuzziness is also described in [RuB89]. The use of a database for control of semiconductor manufacturing is relatively new [Moy91] and leads to a very generic, flexible and portable implementation. Fuzzy theory has been used for control applications [Lee90], but to our knowledge fuzzy databases have not been previously utilized for control of semi-conductor manufacturing. 3.0 Background A brief introduction to concepts of fuzzy sets is given [Zad65], followed by an introduction to fuzzy relational databases [BuP82], [Uma82], [PrT84], [RaM88], [RuB92]. 3.1 Fuzzy Sets Let U be a classical set of objects, called the universe of discourse, and let u denote an element of U. A fuzzy set F in a universe of discourse U is characterized by a membership function: µ F : U [ 0, 1] where µ F ( u) for each u U denotes the grade of membership of u in F. The fuzzy set F may be denoted as: F = { ( µ ( u 1 ) ) u 1, ( µ ( u 2 ) ) u 2,, ( µ ( u n ) ) u n }, where u i Uand µ ( u i ) is the grade of membership of u i in the fuzzy set F, for i = 1,2,...,n. Basic Set Operations. The set operations union and intersection are defined for fuzzy sets A and B by: ( u) = max ( µ and A ( u), µ B ( u) ) µ A B µ A. ( u) = min ( µ B A ( u), µ B ( u) ) Let U = U 1 U 2 U n be the Cartesian product of n universes and A 1, A 2,, A n be fuzzy sets in U 1, U 2,, U n, respectively. The Cartesian product A 1 A 2 A n is defined to be a fuzzy subset of U 1 U 2 U n with ( u 1,, u n ) = min ( µ A1 ( u 1 ),, µ An ( u n ) ) where u i U i, i = 1,...,n. µ A1 A 2 A n 1. Definitions of fuzzy set, possibility distribution and other related concepts are given in Section 3. A Design Methodology for Databases with Uncertain Data* 2

3 Possibility Distribution: A possibility distribution Π for a variable A defined on the domain of discourse U can be defined by a fuzzy subset F of U [RuB92]: The degree of possibility that A takes u as value is equal to the membership value of u in F. Formally, the membership function µ F is identical to the possibility distribution function π A, i.e. π A ( u) = µ F ( u) forall u U. Therefore a fuzzy subset F over U implies the existence of a corresponding possibility distribution with Poss { X= u} = µ F ( u) forall u U. 3.2 Fuzzy Databases Fuzzy Relational Database Model: The fuzzy relational database model enhances the relational model by modeling imprecision in data and/or query. There are two types of imprecisions to be considered, first the imprecision in the degree of membership of a tuple in a relation, and second the imprecision in a data value. First, we present the fuzzy relation construct that expresses the imprecision in the degree of membership of a tuple in a relation, and then the possibilistic relation construct that expresses the imprecision in a data value [RuB92]. Fuzzy Relation: Let U be the Cartesian product of n universes of discourse U 1, U 2,..., U n. Then an n-ary fuzzy relation r in U is a relation which is characterized by a n-variate membership function ranging over U, i.e. µ r : U [ 0, 1]. A tuple of the fuzzy relation r can be expressed as t j = u j1, u j2,, u jn, µ r ( u j1, u j2,, u jn ) with u j1 U 1,, u jn U n. Example: Consider the fuzzy relation EquipmentStatus shown in Table 1. This relation has 2 attributes, EquimentNum (which is the key) and State, and an additional attribute µ r ( a 1, a 2 ) representing the degree of certainty that the EquipmentNum a 1 is in the State a 2. TABLE 1. EquipmentStatus EquipmentNum State µ 234 Loading Alarm Processing, not Alarm 0.4 Possibilistic relation: Let A i for i from 1 to n be attributes defined on the domain sets U i, respectively. Then a possibilistic relation r is defined on the relation schema R(A 1, A 2,..., A n ) as a subset of the Cartesian product of a collection of possibility distributions r P ( U 1 ) P ( U 2 ) P ( U n ) where P(U i ) denotes the collection of all possibility distributions on a universe of discourse U i. A tuple in such a relation has the form: t j = ( Π j ( A 1 ), Π j ( A 2 ),, Π j ( A n ) ) Extensions to the Relational Operators: We now present extensions to the relational operators for fuzzy relations [RaM88], [RuB92]. Fuzzy Equality Relation: A fuzzy relation EQUAL(EQ) over a universe of discourse U is defined to be a fuzzy subset of U U, where µ EQ satisfies the following. For all a, b U: µ EQ ( a, a) = 1(reflexivity) and µ EQ ( a, b) = µ EQ ( b, a) (symmetry). For two tuples t 1 and t 2 in the same relation r, their fuzzy equality can be expressed as: µ EQ ( t 1, t 2 ) = 1 min ( µ EQ ( t 1 [ A 1 ], t 2 [ A 1 ] ),, µ n EQ ( t 1 [ A n ], t 2 [ A n ] ) ) where µ i EQ are functions defined to compare the attribute values A i of the domain U i. This can be used in evaluating queries on the fuzzy relation r of the form: SELECT(r WHERE A i = A j AND... AND A k = c l ), where c l are constants. Similarly, queries with other comparison operators will require appropriate fuzzy comparison functions for their evaluation. Project: The projection r i = PROJECT Ri ( r) of a fuzzy relation r on the schema R i, where R i R, is a k-ary fuzzy relation in dom ( A i1 ) dom ( A ik ). The membership function µ ri is defined by µ ri ( t) = max tr { µ r ( t r ) t r [ R i ] = t} where t r is a tuple of r and t dom ( A i1 ) dom ( A ik ). A Design Methodology for Databases with Uncertain Data* 3

4 Cylindrical Extension: Let the fuzzy relation r i be an instance of R i ( A i1,, A ik ). Also consider a relation schema R(A 1, A 2,..., A n ) where R i R. The cylindrical extension rˆi = C R ( r i ) is an n-ary fuzzy relation on D = dom ( A 1 ) dom ( A n ). The membership function µ of rˆi is given by: rˆ i µ ( t) = µ. rˆ ri ( t [ R i ] ) for t D i Join: Let R 1, R 2,..., R s be relation schemas and R(A 1, A 2... A n ) = R 1 R 2... R s the concatenation of R 1, R 2,... R s. Consider a set of fuzzy relations {r 1,r 2,..., r s } where r i is an instance of R i, i = 1,2,..., s. The natural join of these relations is a fuzzy relation r of the relation schema R. The membership function of r is given by µ r ( a 1 a 2 a n ) = min ( µ ( a rˆ 1 a 2 a n ),, µ ( a 1 rˆ 1 a 2 a n ) ) s where a i dom ( A i ) for i = 1,..., n and rˆj is the cylindrical extension of r j on R for j = 1,..., s Fuzzy Functional Dependencies: Just as functional dependencies are constraints imposed on relations in classical RDBs, a similar constraint can be defined for fuzzy RDBs. A generalization of a functional dependency: X Y in R called fuzzy functional dependency: X Y, can be defined as [RaM88]: A fuzzy functional dependency X Y with X, Y R holds in a fuzzy relation r on R, if for all tuples t 1 and t 2 of r, we have µ EQ ( t 1 [ X], t 2 [ X] ) µ EQ ( t 1 [ Y], t 2 [ Y] ). A functional dependency in a classical database can be viewed as a special case of a fuzzy functional dependency. The Armstrong inference axioms for functional dependencies hold for fuzzy functional dependencies. We can restrict the fuzzy resemblance relation EQ such that in addition to reflexivity and symmetry, it also satisfies ( µ EQ ( a, b) < 1) for a b, a, b U. [RaM88] shows that decomposition based on fuzzy functional dependencies, with EQ satisfying the above restriction, will be lossless. 4.0 Extending the Data Model and Design Methodology for Fuzzy RDBs In this section we present extensions to enhance the ER data model to represent fuzziness. We then describe a design methodology for implementing fuzzy relational databases 1 from fuzzy conceptual data descriptions. 4.1 Traditional ER Model The Entity-Relationship (ER) data model, [Che76], is one of the most popular paradigms for the conceptual data modeling phase of the database design process. The design methodology of [TYF86] outlines three steps for implementing relational databases from an ER schema. The steps may be given as: Step 1. ER modeling of the application requirements: The data requirements are analyzed and modeled using an ER diagram. The basic concepts of ER modeling and their representations in the ER diagram are shown in Figure 1. Step 2. Transformation of the ER model to relational tables: Transform each entity into a relation containing the key and non-key attributes of the entity. For 1-to-1 relationships, add the key of one of the entities to the relation of the other entity involved in the relationship. For 1-to-n relationships, add the key of the entity on the one side to the relation representing the other entity. Transform every n-to-n relationship into a relationship relation containing the keys of the two entities involved in the relationship. Similarly, transform every ternary or higher degree relationship to a relationship relation. Step 3. Normalization of the relations: Normalize all relations to the highest degree desired using functional dependencies and multi-valued dependencies. 4.2 Fuzzy Extensions to the ER methodology We now present extensions to the ER data model and the ER design methodology to cope with fuzzy data. As is generally assumed in the literature, the keys of the entities will be considered crisp, i.e. non-fuzzy Fuzzy Extensions to the ER Data Model: As noted in Section 2, there has been one previous extension to the ER data model [ZvC86]. From that model, we incorporate the use of the f construct to denote 1. The data model considered is fuzzy, but not possibilistic, i.e. individual attributes cannot be fuzzy. We have restricted the data model because our application does not need to handle possibilistic data for now A Design Methodology for Databases with Uncertain Data* 4

5 entity name attribute (key if underlined) name binary relationship with connectivity 1:n, the n-side is shaded ternary relationship Figure 1. ER Modeling Concepts. fuzzy entities and fuzzy relations in the ER model. We go beyond this work by proposing additional extensions to the ER data model as discussed below. Fuzzy Comparison Function: The evaluation of a query on fuzzy data, or of fuzzy queries on crisp data, requires extensions to the query operators (we assume that at the ER modeling stage we already know the entities which may participate in a fuzzy match). Thus for all entities that are involved in a fuzzy match, a comparison function has to be defined for the appropriate comparison operator used in the fuzzy match. We propose to make this an explicit part of the ER methodology. Specifically, we attach the letters fm θ to entities that are to be used in a fuzzy match, where θ is the comparison function for the particular fuzzy match. Example: Consider an entity ActiveEquipment with attributes EquipmentNum and NumberOfProcesses, with the domain [ ]. For the attribute NumberOfProcesses of this fuzzy relation, an EQ comparison function may be defined µ EQ ( a, b) = 1 ( 1 + a b ), for all a, b domain of NumberOfProcesses. The ER schema for this entity is shown in Figure 2. fm EQ NumberOfProcesses ActiveEquipment EquipmentNum Figure 2. ER Representation of the Entity ActiveEquipment. DBFuzzifier: In certain cases it is more useful to consider a crisp entity with one or more attributes fuzzified, rather than considering the entity in its original crisp form. We propose that, in such cases, a new entity EN F can be defined on top of EN by fuzzifying the relevant attributes of EN. Example: Consider a factory maintenance database with two entities, an entity ServiceRequirement, with 2 attributes FrequencyOfService and EquipmentUsage, with the domain {low, medium, high, very high}, and the entity ActiveEquipment of the previous example. A join can be executed between the entities ServiceRequirement and ActiveEquipment, based on the attributes EquipmentUsage and NumberOfProcesses, if we can translate from one of these attribute s domain to the other. One way of carrying out this translation is to partition the attribute NumberOfProcesses in the entity ActiveEquipment into the crisp sets low, medium, high, very high. However a better translation can employ fuzzy theory, and thus define a new entity ActiveEquipment F on top of the entity ActiveEquipment by mapping each instance of ActiveEquipment.NumberOfProcesses into the fuzzy sets low, medium, high and very high. We adapt the fuzzification operator defined in [Lee90] for this purpose. This operator has the effect of transforming crisp data into fuzzy data and is defined by: x = fuzzifier(x o ) where x o is a crisp input value from a process; x is a fuzzy set. Notice the definition of the fuzzifier function depends upon the application requirements. In particular, this definition is determined by the universe to which we are fuzzifying, which determines the mapping of the elements of x o to various fuzzy sets. A Design Methodology for Databases with Uncertain Data* 5

6 We constrain the fuzzifier, now called the DBFuzzifier so that it can be suitably applied to get a fuzzy relation. This operator takes as its input parameters an entity and a fuzzifier defined on an attribute of this entity, and maps this entity to a fuzzified entity. Definition: EN F = DBFuzzifier(EN, fuzzifier(b o )), where EN is an entity with attributes <K, A 1,..., A l, B o >, with key K, non-key attributes A i for i = 1,..., l, and B o the non-key attribute to be fuzzified and for any z = <k, a 1,..., a l, b o > EN, with k K, a i A i for i = 1,..., l, and b o B o, EN F has the collection of tuples z F j = <k, b j, a 1,..., a l, µ(b j )>, for j = 1,..., n, with fuzzifier(b o ) = { µ ( b 1 ) b 1,, µ ( b n ) b n }, i.e., the fuzzifier maps the attribute to a fuzzy set with finite cardinality n. Making an attribute fuzzy would make the entity EN F possibilistic rather than just fuzzy. However, our definition of the DBFuzzifier reduces the relation to a fuzzy (i.e., non-possibilistic) relation. z F j is a fuzzy relation with the composite key k, b j and grade of membership µ(b j ). EN F is thus a fuzzy entity, with crisp attributes, and a grade of membership giving the degree to which the corresponding crisp entity belongs to EN F. Example: Assume we need to fuzzify the entity ActiveEquipment from the last example based on the attribute NumberOfProcesses. The domain of NumberOfProcesses in ActiveEquipment is [0-1,000,000]. In ActiveEquipment F, domain(numberofprocesses) is a fuzzy set over the universe {low, medium, high, very high}. So with ActiveEquipment F = DBFuzzifier(ActiveEquipment, fuzzifier(numberofprocesses o )), each tuple in ActiveEquipment is transformed to up to four fuzzy tuples in Active- Equipment F, one corresponding to each of the four sets low, medium, high, very high. To take a specific instance, the tuple <234, > in ActiveEquipment may be mapped to the tuples < 234, low, 0.1>, <234, medium, 0.9>. The membership grade of in the fuzzy sets high and very high is zero, so there are no corresponding tuple in the ActiveEquipment relation. The ER construct we propose for the DBFuzzifier concept is shown in Figure 3 1. NumberOfProcesses o EquipmentNum ActiveEquipment DBFuzzifier(NumberOf- Processes) NumberOfProcesses f EquipmentNum ActiveEquipment F Figure 3. DBFuzzifier Construct Mapping the Fuzzy ER Model to a Relational Implementation: Once the ER data model has been constructed, the next step requires the mapping of this conceptual model to relations. Fuzzy entities and fuzzy n-to-n relationships can be mapped to relational tables as their corresponding crisp counterparts are mapped (described in Section 4.1), with the exception of adding one more attribute for membership. We must, however, revise the mapping strategy for mapping fuzzy 1-to-1 and 1-to-n relationships to tables. Transforming fuzzy 1-to-1 and 1-to-n relationships to a table: In traditional RDBs, the implementation of a 1-to-1 or a 1-to-n relationship with no attributes does not require a separate table, as the information can be kept in one of the entity tables by storing a foreign key [TYF86]. In a FRDB, a fuzzy relationship necessarily has at least one attribute, namely, the membership grade. Therefore, a fuzzy relationship can no longer be mapped to an entity table, because this will mean associating the fuzziness of the relationship with the entity. 1. In general, the name of the attribute which is fuzzified will be the same in both EN and EN F. To distinguish between the two, we denote this attribute with a subscripted o in the entity EN to which the DBFuzzifier is applied. A Design Methodology for Databases with Uncertain Data* 6

7 Example: Assume there exists a fuzzy relationship SuitedTo between an entity EquipmentType and an entity PrecisionLevel. In our fuzzy ER model, a schema representing this information is shown in Figure 4. Let µ SuitedTo :(EquipmentType,PrecisionLevel) [ 0, 1] be the fuzzy function that maps (Equipment- Type, PrecisionLevel) pairs to a membership value in the fuzzy relationship SuitedTo. If we want to implement the SuitedTo relationship by storing the key of PrecisionLevel with the EquipmentType, we would also have to store the membership value µ SuitedTo in the EquipmentType relation, thus storing an attribute of SuitedTo in the EquipmentType relation. EquipmentType Transforming DBFuzzifier construct and associated entities to tables: The input entity, EN, to the DBFuzzifier as well as the output entity, EN F, should be transformed to individual tables. As an example, in Figure 3, both ActiveEquipment and ActiveEquipment F should be mapped to separate tables. 4.3 Fuzzy Conceptual Design Methodology SuitedTo Figure 4. Illustration of the Fuzzy Relationship Construct. Incorporating the extensions described in Section 4.2 into the ER design methodology [TYF86], we now propose the following design methodology for FRDBs: Step 1: Constructing an extended fuzzy ER data model. Construct the traditional ER model. Attach f to the entities and relationships that are fuzzy. Show the DBfuzzifier construct for entities whose attributes are fuzzified at a different level. Attach fm θ to entities to be used in a fuzzy match, where θ is the desired comparison operator. Step 2: Transforming the ER model to relational tables. Transform crisp entities and crisp relationships to tables as is done for traditional databases (as described in Section 4.1, Step 2). Transform fuzzy entities marked with an f to tables as is done for the corresponding crisp entities, except for adding an additional attribute for the fuzzy membership. Transform both entities associated with the DBFuzzifier construct to individual tables, as is done for other fuzzy entities. Transform all relationships marked with an f to tables, even if these are 1-to-1 or 1-to-n relationships. Add one attribute for the fuzzy membership. Define functions (or make tables) for fuzzy comparison functions for entities marked with fm θ. Step 3: Normalization of the relations. Normalize the relations developed in Step 2 by using functional dependencies, multi-valued dependencies and restricted fuzzy functional dependencies. Step 4: Ensuring correct interpretation of the fuzzy relational operators. This step is related to the operations on the data rather than the data itself. It is needed only if the database management system (DBMS) used does not support fuzzy data. In the absence of such a commercially available fuzzy DBMS, the onus is on the database designer to make sure that the results obtained from a traditional RDBMS conform with the semantics implied by the various fuzzy relational operators described in Section 3. Two possible solutions are either to extend the RDBMS to handle queries on fuzzy data, or transform the results in the host language program for queries embedded in a host language program. f PrecisionLevel A Design Methodology for Databases with Uncertain Data* 7

8 5.0 Fuzzifying the R2R database This section contains a description of an application of the proposed methodology. This application is a run-to-run (R2R) control framework developed to provide supervisory control of VLSI manufacturing processes [CTM93]. R2R process control is a form of sequential (discrete) control that utilizes data from the last run or a series of previous runs to come up with a better model for the next run (Figure 5). R2R Controller Computer Network In Section 5.1, we describe the crisp database. In the following two sections, we describe situations in which this database is unable to providing adequate support to the application. We then describe the fuzzification carried out in each case, based on the fuzzy conceptual design methodology introduced in Section 4, to provide better support for R2R control. 5.1 The R2R Database Plasma Tool Equip Controller Plasma Tool Figure 5. R2R Control Framework. At the heart of the R2R control framework is a Generic Cell Controller (GCC) implementation that serves to support the R2R control algorithm and coordinate control and information flow between the various R2R control modules [MoM92]. The GCC is a reactive device and responds to messages received from external controllers or users. The received message is matched to an entry in the controller database and, if a match is found, the database returns an ordered list of modules which are to be called by the GCC to handle the message. The database contains the necessary information so that the controller can match a valid incoming message to a database entry. The use of a database provides for a generic, portable and compact implementation, and thus offers significant advantages over the traditional approach of hard-coding the controller information The R2R control mechanism is shown in Figure 6. This corresponds to the R2R controller of Figure 5, while some of the control modules shown in Figure 6, e.g., Recipedownloader, Process Starter, will be at the plasma tool equip controller level of Figure 5. An incoming message from a process engineer or a factory controller (1) is received by the GCC. The GCC queries the database to find a match for this message (2). If a match is found, the database returns an ordered list of control routines/modules to be called, along with the parameters to be passed to each of these routines (3). The GCC then calls these routines (4). Each routine may query or update the R2R database during its execution. As an example consider an etch 1 incoming message. To service this message, the GCC calls up the modules returned by the database as the match for the incoming message. These modules for the etch message are: Equipment updater: This module updates the system information in the database. Recipe downloader: This module downloads the recipe corresponding to the desired etch to the equipment controller. Process starter: This modules indicates to the GCC when the process has started, so that the next module, if any, can be called up. When the equipment completes its etch process, it sends a message to the GCC. The GCC again looks up the database, and based on the information received, calls up the following modules: Metrologer: This module collects data corresponding to the actual etch. 1. An etch message is a request for carrying out an etch with specified targets on a semiconductor wafer. A Design Methodology for Databases with Uncertain Data* 8

9 Process optimizer: This module optimizes/controls the process and suggests a new recipe to achieve an etch closer to the target (if the target has not been achieved). Recipe updater: This module updates the recipe in the database to the values advised by the previous module. The R2R control framework described above has been developed on a Sun Sparc 10 workstation, using C++ and C. The R2R database has been developed using an Oracle DBMS, with SQL and Pro C. Run-to-Run Control Database: To explain the design of the database, we follow the steps of the ER design methodology of Teorey et.al [TYF86]. Step 1. ER modeling of application requirements: This is shown in Figure 7 [MoM92]. An incoming Message is matched to a unique ActionNum, which in turn maps to an ordered list of Routines, with each routine having an ordered list of arguments. Step 2. Transforming the ER model to relations: Transformation to relations results in the relations, Message, Action, Routine, RouOrd, Invoke, Routine, ArgOf, Argument, ArgOrd. Step 3. Normalize the relations: There are no functional or multi-valued dependencies, so this step is null. 5.2 Fuzzy Match of the Incoming Message As described in Section 5.1, the R2R database contains the necessary information to match a valid incoming message to a database entry. However in some cases the database may not contain a mapping for an incoming message and the table lookup fails, even though the database may contain messages that are fairly close to the incoming message. We note that fuzzification can be employed here to achieve a fuzzy match of the incoming message if an exact match fails. Hence, we now apply the fuzzy conceptual design methodology proposed in Section 4 to address this problem. Step 1. Constructing an extended fuzzy ER model: A fuzzy match of the incoming messages does not require the introduction of any new entity or relationship to the R2R data schema, shown in Figure 7. For this fuzzy match an = comparison is required, since we want to find out the tuple closest to the incoming message. We thus extend the ER model in Figure 7, by attaching the fm = construct to the Message entity indicating that this entity is used in a fuzzy match with the comparison operator =. Process Engineer/Factory Controller Equipment Controller 1 Process Request 1 Process Request 4 Calls Modules Generic Cell Controller 2 Incoming Message Contol Modules Recipe Downloader 3 List of routines/modules Database Metrologer Process Optimizer Other modules Queries and Updates Control Info System Info Figure 6. Run-to-Run Control Mechanism. A Design Methodology for Databases with Uncertain Data* 9

10 Step 2. Transforming ER model constructs to relational tables : First we transform all the entities and relationships to relations as discussed in Step 2 in Section 5.1. Next an EQ comparison function has to be defined for Message. For this we note that, in general, the actual results achieved by a semiconductor process can be probabilistically characterized. Exact prediction may not be possible because of various random features of the process. In cases where an exact match fails, a normal distribution model for the actual results, with the desired target being the mean of the distribution, can be employed to achieve a fuzzy match between an incoming message and the messages in the database table. The fuzzy match process proceeds as follows. Let m in be the incoming message and m 1,m 2,...,m n be the tuples in the Message table in the R2R database. m in has the form <MessName in, tar 1in, tar 2in,... tar lin > where tar 1in,..., tar lin are the associated l targets (the attribute TargetList models a list of targets). If a corresponding message m i = <MessName i, tar 1i, tar 2i,... tar li,actionnum i > exists in the database, then MessName i = MessName in and tar j,i = tar j,in for j = 1,...,l. This means that a crisp match is achieved for the incoming message. If such a match fails, a fuzzy match is accomplished by using the EQ function on m in and m i as follows: if MessName i MessName in, then else µ EQ ( m i, m in ) = 0 l µ EQ ( m i, m in ) = exp j = 1 ( tar j, i tar j, in ) 2 2 2σ ji where σ j is the standard deviation of the distribution of the actual result for target j. Note that the probability distributions of the results corresponding to various targets have been assumed independent of each other. Step 3. Normalizing the relations: No fuzzy functional dependencies are introduced for this schema, so Step 3 of the FRDB design is null. Step 4. Ensuring correct interpretation of the fuzzy relational operators 1 : This step is carried out by implementing the EQ function in the host language program. Tuples in the message table are matched with the respective attributes of the incoming message, using the EQ function shown above. The user is then presented with a list of matched control messages along with their respective degree of match to the incoming message. The user can then pick one of these messages. MessName Message TargetList Mess_act Action ActionNum RouNum Routine Invoke RouOrd RouOrd ArgOrd ArgOrd ArgOf ArgValue Argument Figure 7. R2R Database Schema. 1. If the DBMS provides support for fuzzy data, this step is not needed. However in the absence of a commercially available fuzzy DBMS, we need to carry out this step as we are a building a real product to be included in an R2R control environment. A Design Methodology for Databases with Uncertain Data* 10

11 5.3 Using Fuzzification to Determine Invocation of Control Algorithms Next, we discuss how fuzzification can be applied to provide support for the execution of one of the GCC control modules. Various algorithms have been developed for R2R control and optimization, e.g. Ultramax 1, and a linear approximation algorithm [Hu92]. Fortunately, the scope of application of these algorithms is not very well-defined and there does not appear to exist any single algorithm that may be used throughout the entire range of R2R control and optimization [CTEM93], [MEE93]. However, the ranges of applicability of these algorithms are roughly known in terms of the process being near or far from its optimum, which we can model using fuzzy theory. In the original implementation of the GCC, described in Section 5.1, the comparison data between the actual results and the desired recipe targets is not utilized for making decisions regarding choice of control algorithms. However, this scenario of having only rough knowledge of the applicability of the control algorithms seems to lend itself well to a fuzzy solution. We, therefore, employ fuzzification for making decisions about which control algorithms to use corresponding to the differences between the desired targets and actual results. We use our fuzzy conceptual design methodology to develop extensions to the R2R database for fuzzy decision making. This extension is used by the process optimizer/control routine (an instance of the entity Routine of Figure 7), which is called up to service a done message (an instance of the entity Message in Figure 7). Step 1. Constructing an extended fuzzy ER model: First we construct the ER model. We know which algorithms perform better roughly in terms of high, medium or low errors. This is modeled as a fuzzy relationship IsApplicableTo between the entity ErrorType and the entity Algorithm (Figure 8). The attribute Type of the entity ErrorType has the fuzzy domain {High, Medium, Low}, indicating the scope of applicability of each algorithm. For every run, the difference between the target and actual result can be calculated and is modeled as the entity Difference. However the domain of the attribute Value of Difference is a number. To join Difference with the relationship IsApplicableTo, a DBFuzzifier construct needs to be used on attribute Value of Difference to get the entity Difference F. So the fuzzifier for Difference F = DBFuzzifier(Difference.Value o ) is: value = fuzzifier(value o ), with value = { µ ( High ) High, µ ( Medium ) Medium, µ ( Low ) Low }, where ( value o σ 3) 2 µ ( High ) = exp 2σ 2, ( value o σ 2) 2 µ ( Medium ) = exp, and 2σ 2 ( value o σ 1) 2 µ ( Low ) = exp, where σ is the standard deviation of the difference between the target and the result 2. Roughly speaking, errors around 1 σ are low, around 2 σ are medium, and around 3 σ 2σ 2 are high. The fuzzified difference can then be joined with the relationship IsApplicableTo to fuzzily determine which algorithms are suitable for carrying out control for this particular run. The schema for this is shown in Figure 8, using the ER model with fuzzy extensions. None of the entities in Figure 8 are represented in Figure 7 (the original ER model of GCC), as fuzzy decision making for choosing control algorithms could not be modeled by the crisp ER model. Step 2. Transforming the ER model constructs to relational tables : Using the fuzzy conceptual design methodology, we map the entities ErrorType and Algorithm to relations. The n-to-n relationship IsApplicableTo is also transformed to a relation, as are the entities Difference and Difference F. 1. Ultramax is a trademark of the Ultramax Corporation, Cincinnati, Ohio. 2. For simplicity, we assume that there is just one target for the process being optimized. If the number of targets is greater than one, the model is easily extended by taking the union of the fuzzified differences for each of the targets. A Design Methodology for Databases with Uncertain Data* 11

12 Num Difference Value o dom(value o ) = Real Numbers dom(value) = {High, Medium, Low} Num Difference F f Value Type IsApplicableTo Routine ErrorType Example: The table IsApplicableTo implemented for R2R control database is shown in Table 2. TABLE 2. IsApplicableTo Routine Type µ Is_applicabe_to Ultramax high 0.7 Ultramax medium 0.4 Rapid high 1.0 Gradual medium 0.5 Gradual low 1.0 Step 3. Normalizing the relations: No fuzzy functional dependencies are introduced for this schema, so Step 3 of the FRDB design is null. Step 4. Ensuring correct interpretation of the fuzzy relational operators: For each algorithm, we want to determine the degree of certainty that it is applicable for a particular run of the semiconductor process. For this we need to first join the table IsApplicableTo and the fuzzified Difference for that run, and then a project on Routine to get the name of the routine and the degree to which it is applicable to the present run. Example: Let d = {0.449 / high, / medium, 0.48 / low} be an instance of Difference F. Joining with the table IsApplicableTo results in the Table 3. TABLE 3. Result of a join between Table 2 IsApplicableTo and d, an instance of Difference F. Routine Value/ Type Grade = min(value,type) Ultramax high min(0.7, 0.449) = Ultramax medium min(0.4, 0.818) = 0.4 Rapid high min(1.0, 0.449) = Gradual medium min(0.5, 0.818) = 0.5 Gradual low min(1.0, 0.48) = 0.48 Now projecting over Routine gives us Table 4. TABLE 4. Projecting Table 3 over Routine. Routine Grade Ultramax = max(0.449, 0.4) Rapid Gradual 0.5 = max(0.5, 0.48) f Algorithm Figure 8. Fuzzy Data Model for the Determination of the Invocation of Control Algorithms. A Design Methodology for Databases with Uncertain Data* 12

13 6.0 Conclusions and Further Research Several proposals for extending relational database systems in order to represent imprecise data utilize fuzzy set theory as the formalism for modeling uncertainty. However, little work has been done in modeling uncertainty at the conceptual schema level. More importantly, there have been no results reported on any design methodology for the development of fuzzy relational databases. In this paper, we proposed a design methodology for FRDBs. This methodology, extends the ER methodology for crisp relational databases [TYF86]. In particular, we first extend the ER model with powerful fuzzy extensions (at the graphical level as well as with formal definitions of extensions). Thereafter, we present a new design methodology that maps such fuzzy ER models to fuzzy relational databases. We then explain the design and implementation of the R2R control database for supervisory control of VLSI manufacturing. We demonstrate the need for support for handling imprecise data for R2R control. Following this, we describe fuzzy extensions to the R2R control database achieved by using our design methodology for FRDBs. For future research, we note that the design of fuzzy databases involves modeling not just the data but also modeling operations on the data. The ER model is exclusively concerned with the structure, but not the behavior of the data. It would thus be interesting to look at other more powerful modeling techniques such as object-oriented modeling, which captures structural and behavioral abstractions, to model fuzzy data. Since fuzzy and possibilistic databases allow comparatively complex data types (e.g., possibility distribution functions), object-oriented databases seem to be a suitable paradigm for explicitly modeling complex data types. For enhancing support for R2R control, we also need to investigate active databases to see how the eventcondition-action paradigm of this technology be utilized for R2R control - in particular, in the context of imprecise data or imprecise rules. 7.0 Acknowledgments This research is supported by the Semiconductor Research Corporation and ARPA. The authors would like to acknowledge the help of Professor Toby Teorey for review of an earlier version of this paper. The help of Hossein Etemad, Roland Telfeyan and Brian Moore in developing the GCC is also gratefully acknowledged. 8.0 References [BuP82] B. Buckles and F. Petry, A fuzzy representation for relational databases, Fuzzy Sets and Systems 7 (1982), [Che76] P. Chen, The entity-relationship model - toward a unified view of data, ACM TODS 1, 1 (March 1976), [CTM93] N. Chaudhry, R. Telfeyan, B. Moore, H. Etemad and J. Moyne, A run-to-run control framework for VLSI manufacturing, Techcon 93 Conference Proceedings, September 1993, [FSI91]I. Fujishiro et.al., The design of a graph-oriented schema for the management of individualized fuzzy data, Japanese Journal of Fuzzy Theory and Systems 3, 1 (1991), [Hu92] A. Hu, An Optimal Bayesian Process Controller for Flexible Manufacturing Processes, Ph. D. dissertation, MIT [Lee90] C. Lee, Fuzzy Logic in Control Systems: Fuzzy Logic Controller-Part 1, IEEE Transactions on Systems, Man, and Cybernetics 20, 2 (March/April 1990), [Moy91] J. Moyne, Generic Cell Controlling Method and Apparatus for Computer Integrated Manufacturing System, Patent Application filed with the United States Patent and Trademark Office August [MoM92] J. Moyne and L. McAfee, A Generic Cell Controller for the Automated VLSI Manufacturing Facility, IEEE Transactions on Semiconductor Manufacturing 5, 2 (May 1992), [MEE93] J. Moyne, H. Etemad and M. Elta, A run-to-run control framework for VLSI manufacturing, SPIE Conference, Sep [PrT84] H. Prade and C. Testemale, Generalizing database relational algebra for the treatment of incomplete or uncertain information and vague queries, Information Sciences 34 (1984), [RaM88] K. Raju and A. Majumdar, Fuzzy Functional Dependencies and Lossless Join Decomposition of Fuzzy Relational Database Systems, ACM TODS 13, 2 (June 1988), A Design Methodology for Databases with Uncertain Data* 13

14 [RuB89] E. Rundensteiner and L. Bic, Semantic database models and their Poetential for capturing imprecision, Conf. on Management of Data, [RuB92] E. Rundensteiner and L. Bic, Evaluating aggregates in possibilistic relational databases, Data and Knowledge Engineering 7 (1992), [TYF86] T. Teorey, D. Yang and J. Fry, A logical design methodology for relational databases using the extended entity-relationship model, ACM Computing Surveys 18, 2 (June 1986) [Uma82] M. Umano, Freedom-0: A fuzzy DB system, in Fuzzy Information and Decision Processes, eds. M. Gupta and E. Sanchez, North-Holland. [UnF92] M. Unano and S. Fukami, Perspectives of Fuzzy Databases, Japanese Journal of Fuzzy Theory and Systems 3, 1 (1991) [Zad65] L. Zadeh, Fuzzy Sets, Information and Control 8 (1965) [ZeK85] M. Zemankova-Leech and A. Kandel, Implementing Imprecision in Information Systems, Information Sciences 37 (1985) [ZvC86] A. Zvieli and P. Chen, ER modeling and fuzzy databases, in Proc. of the 2nd International Conference on Data Engineering (1986), A Design Methodology for Databases with Uncertain Data* 14