A Methodology for View Integration in Logical Database Design

A Methodoloqy for View Inteqration in Loqical Database Desiqn

Shamkant 6. Navathe Database Systems Research and Development Center 512 Weil Hall University of Florida, Gainesville, Florida 32611

Suresh G. Gadqil Metropolitan Life Corporate S.Ystem Planninq 1 Madison Avenue New York, New York 10010

Abstract It is assumed that user views would be explicit- ly represented using some data model. The View This paper is based on a conceptual frame- Representation Model of Navathe and Schknlnick work for the design of databases consisting of [ 111 is used as a representative model and a view modeling, view integration, schema analysis methodology for inteqratinq such views is and mapping and physical design and optimiza- discussed. tion. View modeling involves the modeling of the user views using a conceptual/semantic data model; the view integration phase merqes user 1.1 THE DATA BASE DESIGN PROCESS views into a global model which is then mapped to an existing database environment and subse- The conceptual framework for the desiqn of quently optimized. Here we use the data model data bases as described in some of Navathe's proposed by Navathe and Schkolnick to model user previous work [11,16] and as qenerally accepted views and develop a methodo1og.y for view inte- at the 1978 New Orleans data base desiqn work- gration. View integration issues are examined shop [;I] may be described in terms of four in detail; operations for merging views are steps. The input to these four steps stems from defined and an approach to automating the view a Requirements Analysis step which provides a integration process is described. The proposed specification of data and processing require- approach is being partially implemented at the ments. The four steps are: University of Florida. A. View modelinrl: in this first sten the user's view of the real world is abstracted and 1. INTRODUCTION represented.

It can be said without any doubt that one 8. View Integration: the user views are of the major obstacles to the use of database combined into a qlobal model of the data and any management software is the initial preparatory conflicts in the process are presented for effort during logical database design. It is resolution. certainly a difficult task to design a "community view" of a single database which truly C. Schema analysis and mapping: the global reflects the aggregation of views with different model is mapped to the logical structure of an

expectations, backgrounds and technical exper- existing database management system. l tise. For realistic databases used in business, industry and government with thousands of D. Physical schema design and optimization: potential users, an individual user or user the logical structure is analyzed with respect group cannot be expected to be aware of the to physical design alternatives and an "optimal" needs of the rest of the user community and a physical schema is constructed. designer cannot be knowledgeable enouqh to comprehend the requirements of a spectrum of This conceotual framework is illustrated in users. Fiqure 1.

A natural way to start, therefore is b.y collecting the views of user groups or applica- 1.2 OBJECTIVE AND SCOPE tion areas individually. The problem of coping with thousands of data elements/attributes or A major problem in database design is the hundreds of data objects is ver.y difficult to lack of a structured desiqn methodoloqv and lack deal with manually [12]. In this paper we of automatic aids for developing complex data- present an approach to alleviating this prol?lem. bases. Research has been conducted with the

proceedings of the Eighth International Conference 142 on Very Large Data Bases Mexico City, September,‘W82 goal of structuring this process [12,15,17-J. Instances of an entity tvpe are called entities. Further, a few automated techniques which Entities refer to physical things, persons, address parts of the database design process and concepts. An entity type may either be self- others oriented towards particular database man- identified or externally identified. An asso- agement systems are available; examples are ciation type refers to a collection of associa- PSL/PSA [14] used primarily for requirements tions. Associations are n-ar.y relationships specification; and Database Design Aid (DBDA) defined over entity types and association types. [12] used for a specific database management They are subdivided into two subtypes: simple system. We had proposed in [16] the framework associations and identifier associations. The for a structured database design methodology subtypes of a simple association type are: consisting of the above 4 steps and surveyed cateqorization, subsettinq and partitioninq research done to date related to those steps. types. In [ll] we described how the first step of view modeling may be accomplished. Connecter types in the N-S model connect an association type to some object tvoe which par- This paper addresses the View Integration ticipates in the association type. They are step. It assumes the use of the specific data divided into two subtypes: directed and undi- model namely, the Navathe and Schkolnick model rected. A directed connector type implies [ll], for representing views and analyzes the certain rules of insertion and deletion in the process of view integration. The aaper dis- context of an association type. In qeneral, cusses the different problems related to the connector types are used to show three types of view integration process and proposes an dependencies among object types: ownership, approach to the development of a software system deletion and null dependency. They are illus- for automating the construction of integrated trated in Fiqure 3. views. We are presently implementing these ideas in the database design aid in conjunction The N-S model representation conventions with a data dictionary system being developed at allow view diagrams to be drawn. These diaqrams the University of Florida. Efforts are also are supplemented with assertions to state com- under way to consolidate the research on view plicated interdependencies among instances. An integration by collaborating with the University assertion lanquage may be defined to state these of Rome where similar work is being pursued on assertions. We are presently investigating the the extended E-R model [2]. To our knowledqe, adequacy of a language based on the first order very little work has been done on the view predicate calculus. The language must be capa- integration problem, barring a few exceptions ble of expressing the following kind of asser- c51. tions: For the view diagram in Fig. 18 -

"Procedures performed by the SERVICE 2. MODELING USER VIEWS instance called Hospital-trust are always performed free" is an assertion in natural For ease of discussion and because of some language. The same in an assertion of its desirable features we have chosen the language could be stated as - model proposed by Navathe and Schkolnick [ll] (henceforth abbreviated as the N-S model) as a s.Service-Name = Hospital-trust & vehicle for modeling user views. A brief e PROCEDURE-IDENTIFIER & description of the model and its advantages E PERFORMED ==> follows. E PERFORMED-FREE.

where: s,p,c,r are respectively instances of 2.1 SUMMARY OF THE NAVATHE-SCHKOLNICK MODEL entity types SERVICE, PROCEDURE, SCHEDULE and PERSONNEL. The N-S model includes the two as ects of user requirements identified by Kahn [6 !i : "the Assertions pertaining to a single view are Information Structure perspective" describing termed intra-view assertions whereas those data by means of entity types and association pertaining to multiple views are termed inter- types, and "the usage perspective" giving a view assertions. description of processing and insertion/deletion of instances of these types. The discussion of For a further clarification of the N-S the view integration process itself is mostly model the reader is referred to the Appendix in invariant to the model selected and will be done the paper and to Clll. in a general way. The N-S model allows the modeling of user views in explicit terms. The Note: The words 'type' and 'instance' will be model uses two type constructs: objects and used in the subsequent discussion only connectors. The object type is divided into two when they seem necessary. subtypes: entity type and association type.

Proceedings of the Eighth International Conference ., 143 on Very Large Data Baser MexitiCity, September,1969 2.2 ADVANTAGESOF THE N-S MODEL Equivalent Views are defined as views which have the same information content but different a) It allows association types to be structures. The term information content refers defined over entity types, over association to the functional and non-functional associa- types, or a combination of both unlike the E-R tions among attributes. Information content has model [23. been defined formally for relational databases in terms of functional dependence and direct b) Models the existence-dependencies among table look-up associations [l]. In this paper entities separately (in terms of identifier we will assume that an acceptable measure of associations) from the relationships (or associ- information content has been defined for the ations) among entities (unlike Smith/Smith user c0mmunit.v in question.

C131) l It thus defines identification paths clearly. (e.g. PROCEDUREin Fig. 19 is exis- A tarqet of integration is an object type tence-dependent on SERVICE b.y virtue of identi- or a c-o?;-type which is compared among fier association PROCEDURE-IDENTIFIER), different views for possible integration.

C Describes a view of terms of object A view integration operation is a process We 1which are either entities or associa- that is applied to the targets of integration tions). The internal hierarchy of descriptor giving rise to new object types, connector elements (attribute types) within an object type types, attribute types etc. These operations is kept separate from the object type interac- are discussed in greater detail in a later sec- tion since .it is less important. For example tion. A preferred view is that view which is the internal structure of A in Figure 4 namely, selected from amonq two or more equivalent views A(A,b,(c,d),(e,(f))) is a further level of for inclusion in the Global View over a less detail about entity type A. preferred view. The inteqration policy is defined as the set of rules which dictate how a d) Models data relationships as seen b.y number of local views must be integrated into an user both at schema and instance level. Proper- Enterprise View. The policy contains several ties of views with respect to insertion/deletion rules; examples of these rules are: rules etc. are clearly distinguished (unlike Chen [2] and Smith/Smith [13]) by use of differ- "The user views in Finance Dept. are to ent subtypes of association types and by employ- be preferred over user views in Market- ing directed connector types. ing Dept. at all times."

or "In categorizing patients, select those 2.3 GLOSSARY OF VIEW MODELING AND INTEGRATION categorizations which correspond to the TERMS physical allocation of wings in the hospital (e.g. Psychiatric, Obstetric, A user view is a representation of informa- Intensive Care, etc.)." tion structure and processing requirements as seen by a group of users. A subview is a subset The integration polic.y, after all, is subject to of a user view. The subsequemussion about interpretation by the designer. It should be user views is equally applicable to subviews. couched in the form of a scale of preferences of views and intra-view and inter-view assertions. The View Integration process has as its objective the development of a conceptual model supporting all users in the organization. This 2.4 EQUIVALENCEOF VIEWS conceptual model will be called as a Global View. The Global View ma.y in fact con- A comparison of two views can be made to num6er of views that cannot be further inte- determine whether the.v are identical. Identical grated. The software system to accomplish view views have objects and connectors that match integration will be called a View Integrator. completely. In some cases the identical nature of two views is made apparent only after naming The Enterprise View forms a nucleus for correspondences are established. development of the m View. It describes the basic entities and associations appropriate Views which are not identical are referred for the organization and is based on the assump- to as non-identical and may be classified tion that some characteristics of data structure further into Equivalent and Non-equivalent and usage can be deduced from the nature of the views. A pairwise matching of views can lead to organization. the grouping of a set of views into subsets shown schematically in the following hierarchy:

Proceedings of the Eighth International Conference on Very Latgs Data Bases 144 Mexico City, Sap$wnbar, 1982 Views of the Enterprise View and local views; the Inter-view assertions describe certain characteristics of views which need to be taken into account in the inteqration process. Identical Non-identical Other outputs of the View Inteqration (may have naming conflicts) process are - Mappinq Rules and a Statement of Conflicts. The Mapping Rules describe how individual local views can be generated and how user A processing requirements can be satisfied. The Equivalent Non-equivalent nature of mapping rules depend upon the way in which processing requirements are specified. E.g. if an access path specification is used to describe processing requirements, a mapping .rule Representation ARestructure may state that the original access path is equivalent Equivalent obtained b.y a combination of access paths in the global view. The statement of conflicts pre- sents conditions which could not be resolved during the integration. Equivalence of two views arises from two sources: the use of different modeling cons- The view integration model is presented tructs and conventions resulting in Representa- schematically in Figure 7. tion Equivalence; genuine differences in how the same data are viewed by the modeler/designer The following assumptions and statements resulting in Restructure Equivalence. Restruc- further define the scope of view integration in ture Equivalence is so named because each of the the present paper: equivalent views can be transformed into the other by a set of restructuring operations such a) a sinqle result: the Global View which as compression, expansion, assembly merging and really consists of multiple views is to be assembly partitioninq [lo]. The distinction produced. The model does not consider develop- between these two types of equivalences is ment or presentation of alternative Global motivated by the fact that the complexity of Views. view integration operations is greater in dealing with Restructure Equivalent views. Since b) due to errors or inadequate definition the boundary between these two is at best arbi- of input views or assertions the integration trary, some convention must be adopted to sepa- step produces a statement of conflicts wherever rate the two. In 'this paper our convention will necessary after designer intervention. be as follows: if two views have objects and connectors which match except for differences in cl it is assumed that a "normalization of prime and candidate keys, they will be consi- input user views" is carried out corresponding dered representation equivalent. Figure 5 shows to the first normalization of the relational two Representation equivalent views. Figure 6 model [4] to eliminate all Identifier Associa- shows two Restructure equivalent views where tions. The normalization process propagates View 2 has entity type DEPTS categorized into keys within the data structure so that all categories MEDICAL, SURGICAL, NON-MEDICAL- objects become self-identified. Figure 8 illus- NON-SURGICAL but contains the same information trates how the identifying association linking as in View 1. The equivalence is not apparent LABORATORYand CHIEF is removed by propagating unless it is specified. LabName into CHIEF, i.e., expanding the key of CHIEF from ChiefName, to Labname, ChiefName to Restructure equivalence among views to be make it self-identified. Navathe LgJ has dis- integrated generally requires identification of cussed an intuitive procedure to normalize the preferred views(s) and gives rise to the network structured data which can be applied development of mapping rules during integration. when a network of identification paths is The preferred view is incorporated into the present. Global View with as little change as possible. Less preferred views are accommodated by means of mapping rules which enable the non-preferred 3.1 INPUTS TO THE VIEW INTEGRATOR view to be reconstructed from the Global View. The inputs to the View Integrator are the Enterprise View, the local views, assertions and 3. A MODEL FOR THE VIEW INTEGRATION PROCESS *(processing requirements. In this paper we do not elaborate on how processing requirements A Global View is developed from the input within each view are specified. views and assertions. The input views consist

Proceedings of the Eighth International Conference 146 on Very Large Data Bases Mexico CiW, September, 1982 A. THE ENTERPRISE VIEW 3.2 OUTPUTS OF THE VIEW INTEGRATOR

The Enterprise View is constructed by the A. THE GLOBAL VIEW designer based on his knowledge of the orqaniza- tion. It will include many of the entities in A Global View is a conceptual model of data the final database design. For example, in a which subsumes the Enterprise View and all database for a Medical Center an Enterprise View pertinent user views within an organization. may consist of entity types DOCTORS, PATIENTS, The Global View is characterized by a minimum of TESTS, MEDICATIONS, NURSES and PROCEDURES. data redundancy and inclusion of all access paths for data retrieval of object instances 8. LOCAL VIEWS from all user views. A Global View is the most significant output of the View Integrator; it is Local Views are views of data seen by the input to the next phase in logical database individual users or user groups in the organi- design namely, Schema Analysis and Mapping, zation. They are modeled using the N-S model which maps the database design to a target with entities and associations. The.v yvprEe database management system. supplemented b.y intra-view assertions. ferred local view and its intra-view asser- B. MAPPING RULES tion(s) are carried forward unchanged as far as possible during integration; some local views Mapping rules state the access paths for undergo changes during integration. However, data and include the deletion and insertion unless deliberately deleted, no information from rules for views which are equivalent. Mapping any view is supposed to be lost. Rules are derived from inter-view assertions. They represent the means by which data specified C. INTER-VIEW ASSERTIONS in a non-preferred view may be obtained from the Global View. The complexity of mapping rules Inter-view Assertions circumscribe the view depends upon the number and type of restructur- integration process by specifying views which ing operations required to transform one view are equivalent. They state in what way views into its equivalent. are equivalent and the data correspondence from one view to another. Data correpsondence is Mapping rules may be illustrated with stated in terms of names of entities, associa- reference to Fiqure 6 which shows two restruc- tions and attributes and, where appropriate, the ture equivalent views. Inter-view assertions restructuring operations to convert one view to for these views have been stated earlier. A another. An example of an inter-view assertion mapping rule for these views would be: for Restructure equivalent views shown in Figure 6 is: DEPTS ==> DEPTS t MEDICAL t SURGICAL t NON-MEDICAL/NON-SURGICAL 1. View 2 = RSTR[View 11 2. Preferred View = View 2 where t indicates a union operation for access 3. View 2 [MEDICAL, SURGICAL, paths. NON-MEDICAL-NON-SURGICAL] ==> CATEGORIZE [View 1 The mapping rule siqnifies that references [DEPARTMENT]/TYPE] to the entity DEPTS of the non-preferred view - View 1 requires access to all the entities named The first two statements above are self- on the right hand side of the mapping rule in explanatory. Statement 3 specifies the restruc- the Global View. For Fig. 10, a maopinq rule to turing operation called CATEGORIZE which trans- obtain View 1 would indicate that XCeSSiW forms entities from one view to another. (see DEPARTMENT by Oeptname would involve a table- assembly partitioning in [lo]). In this example look-up operation of looking up a Deptno for the entities MEDICAL, SURGICAL, NON-MEDICAL-NON- Deptname first. SURGICAL are categories of the DEPARTMENT entity of View 1 by the attribute type called Type. 3.3 A GENERAL PROCEDURE FOR VIEW INTEGRATION Inter-view assertions are also used to specify prime and candidate keys in representa- In a semi-formal manner the view integration equivalent views. The inter-view assertion process may be described as follows. tions for Figure 15 are:

View 1 = REP[View 21 Inputs 1. '_.

2. Prime key: ServiceNo.; Candidate key: Assume an enterprise view E and local views ServiceName. VI, . .. V, as given.

Proceedings of the Eighth international Conference on Very Carge Date Bases 146 Mexico City, Septem&$B2

_ .~ P = given integration policy Step 3: Provide feedback to the desiqner on = a set of intra-view assertions the intermediate results of : = a set of inter-view assertions integration IVI, . . . IV . (These R = a set of processing requirements include local views whichPwere in a class by themselves). Ask designer outputs to provide a preference ordering of these semi-integrated views. G= global view set M = a set of mapping rules S = a set of conflicts Step 4: Integrate views IVi into E in A modified set of assertions descendinq order of preference in a way similar to step 2.

A step-by-step procedure for view integration: - Modifv assertions in I and J on the basis of how the inteqration Step 1: Divide views V orocess affects the components classes CI, . . . v suchl ** thatvn eachinto of an assertion. class contains eitker - Report conflicts back to the - a set of equivalent views designer and ask the designer to (either restructure or represen- make a choice, add or modify an tation equivalent), or assertion etc. If a conflict cannot be resolved add it to set - a set of identical views, or S.

- a sinqle view (which is not - Repeat step 4 as long as view identical nor equivalent to a inteqration operations are view in another class). applicable. The applicatlP,;i;; specific operations Verif.y the classes b.y checking with integration is extremely diffi- the designer. cult to figure out automatically on the basis of naming, struc- Set class index i to 1. tural similarities and assertions. The designer may be required to control this process Step 2: Perform an inteqration on class Ci. (see [21).

If the class contains identical The result of step 4 is the set G views, select one as the integrated of global views. Ideally G should result: IVi. contain a single view but practi- cally it may not. Step 4 may need If a class contains equivalent to be reapplied after some modifi- views, attempt to generate an cations. integrated view IVi,

- by applying P Step 5: Generate M b.y determininq how each of the requirements in R is satis- - by treating views in descending fied by using G. (Generation of M order of preference may alternately be carried out during Steps 2 and 4).

- by reporting back conflicts to the designer and asking the designer to 4. THE MATCHING PROCESS IN VIEW INTEGRATION make a choice (of names, of keys etc.) or making new assertions or The view integration operations to be modifyinq old ones. applied to views are determined b.v comparing the views to be inteqrated. At the object type - by considering I and J during level, simi1arit.y of objects is determined by inteqration. comparison of attributes and keys; at the view level, the comparison is between objects and If a single integrated view cannot be connectors from one view with another. The generated, multiple intermediate views matching process is used in Step 1 of the view may be generated and passed to the next integration procedure to divide views into step. classes. There are three possible outcomes of

Proceedings of the Eighth International Conference on Very Large Data Bases 1 r-1 Mexico City, September,. 1982 the matching process: complete match, partial The union operation on the attribute sets match or mismatch. above is supposed to eliminate duplicate attributes although their names may not be It is assumed that two completely matching identical. The duplication is inferred from object types will have completely matching assertions. instances. The reason behind such an assumption is that at the logical database design stage no Figure 9 illustrates a partial match on conclusions can be drawn regarding actual values key; the entity type *DEPARTMENThas key attri- in instances of data. If details about the bute UivNo, UaptNo in view 1 which is preferred. values are available, they may be supplied by After integration, the same key applies to means of inter-view assertions: DEPARTMENT. Figure 10 illustrates a mismatch on key. Deptno from the preferred view 2 is

e.g., Value-set (View 1 l PLACE-OF-ORIGIN) selected as a key in the target view. Ueptname I 'US','OTHER' , - remains as a non-key attribute type. Figure 11 illustrates a case with no match on name between

Value-set (View 2 l PLACE-OF-ORIGIN) entity types NURSE-STATION and RECEPTION- = 'US' ,' EUROPE','ASIA','OTHER' STATION. However, an inter-view assertion (possibly input by the designer after ascertaining that they mean the same) forces a match 4.1 OBJECT SIMILARITY among them. Matronname and Head-nurse-name are also supposed to be declared as identical attri- Object similarity is determined first by bute types. The names, key etc. from the pre- comparing the names of the object types and then ferred view are carried to the integrated view. by comparing the attribute names and definitions of the object types. This matching results in Table 1: Outcomes of Object type matching either a complete match or a partial match or a mismatch. The conditions of complete match and Match Type Match On complete mismatch are easy to visualize. Match- ing names are reported to the designer for con- Name Key attributes attributes firmation that they have identical meanings. The partial match conditions arise out of a com- Complete 1 Completer Complete 1 \y;:eate bination of complete match, partial match, and mismatch when key attributes and non-key attri- No Match _ butes from different objects are compared. Partial Complete Partial The range of outcomes of the matching No Match process is illustrated in Table 1. No Match Complete Partial The general rules for resolving partial No Match matches and mismatches are described below. Partial No Match Complete Complete Partial Let 0 be an object type being matched; 0 No Match is from a preferred local view, O2 is from a Partial Complete non-preferred view and OS is the result of Partial integrating OI and 02. No Match No Match Complete Let Key(Oi) = set of key attribute types in I Partial Oi' Mismatch 1 No Match No Match No Match N-Key(Oi) = set of non-key attributes 4.2 SUBVIEW OR VIEW SIMILARITY types in Oi. Assume a situation in which local views are a) Partial match on key - matched by extracting subviews made up of one or more unary, binary or n-ary associations and W(Og) = W(Ol) matching them among themselves. A subview thus has at least two objects and may have ownership N-Key(03) = N-Key(OI)u N-KeY(02)u and deletion dependency characteristics by {KeY(O2) - Key(OI)} virtue of directed connectors. Subview similarity may be determined by a comparison of object b) Mismatch on key - types and a comparison of dependencies. At a minimum we can consider two object types and the Kw(Og) = @Y(Ol) ownership and deletion dependency, whichever are applicable, between them. Object matching has N-Kw(03) = N-Key(OI) u {N-Key(02) already been discussed in terms of name, key - IVY) u Key(02) attributes and non-key attributes of the object

Proceedings of the Eighth International Conference 148 on Very Large Data Bases Mexico City, September, 1982 types. As regards different dependencies, we operations can be defined at two levels: schema have three states, viz., ownership, deletion (type) operations and instance operations. dependency and null dependenc.v in each of two Instance operations would apply to individual views, giving a total of nine combinations. In instances of objects (e.g., delete instances the matching process we consider the combination where age > 75). A view integrator need not [Ownership (View l), Deletion Dependency (View really support such operations during desiqn. 2)] the same as [Deletion Dependency (View l), They may be provided in the form of modifica- Ownership (View 2)]. Therefore, we have to tions of-assertions. consider only the following six cases: Schema operations consist of operations on associations and connectors. The former operate Table 2: Different combinations of dependencies on the three kinds of special associations: Type of Dependency categorization, partitioning and subsetting. The latter operate on connector types. Combination # View 1 View 2 Match Outcome Ownership Ownership : Deletion Deletion Complete Match 4.3.1. ASSOCIATION TYPE OPERATIONS 3 Null Null 4 Ownership Null Partial Match Categorization Addition Is the additon of a new categorlzatlon of an entity-type. Figure 12 5 Deletion Null 6 Ownership Deletion Conflict shows the integration of two views with different categorizations of the same object PATIENT. The integrated view is obtained b.y merging the Combinations 1, 2 and 3 represent conditions of complete match and the merging process PATIENT entity and the addition of categoriza- can continue. Combinations 4 and 5 represents a tion ADMISSION-STATUS to an existing cateqorira- partial match and require resolution in one of tion AGE-GROUP. Assume that mutual exclusivfty two ways: maintain both relationships with was given as an intra-view assertion. The implication on instances is that a given patient re ndant object types or provide mapping rules so that data for each of the two views can be has one instance of type PATIENT, one of either type INPATIENT or type OUTPATIENT and one of ob ained from the Global View without any redun- either type PEDIATRIC or type ADULT. da cy. The latter method is chosen in keepinq with one of the objectives of inteqration n mely, to minimize redundancy. This is in con- Category Enhancement is the addition of a / new category type supplementinq an existinq trast to El Masri and Wiederhold's approach [5] categorization. Category, enhanckent is illus- where they require that partially matched trated in Figure 13. The two input views show objects from equivalent views in the Global different categorizations of the PROCEDURE Model be maintained AND consequent insertion and deletion of instances of these objects be entity type. The integratlon of these views results in one categorization association of the handled consistently. The approach in [5] has the advantage of preserving the same view of PROCEDURESentity type into four entity types. This operation is similar to the categorization data as originally defined by each user in the addition except that (i) no new categorization Global View but results in a heavy data redun- association is added here; only new category dancy as well as increases processing overhead. types are added to an existing categorization. If mutual exclusivity is to be enforced, cate- As a general policy, the integrated view for Combinations 4 and 5 will include the more gorization addition is preferred. constrained of the views being integrated Partition Enhancement involves the addition namely, View 1 in Table 2. Combination 6 shows of partitions to an existing partitioning asso- a conflict in two views which cannot be resolved ciation. Partition enhancement is illustrated automatically. This condition requires designer in Figure 14 where View 1 and View 2 have a par- intervention followed by a specification as to titioning of the EMPLOYEEby EMPLOYEETYPE. The the preferred view. entity type called EMPLOYEE-TYPE is shown in terms of its instances, e.g., NURSE and DOCTOR in View 1. Each of these instances is supposed 4.3 VIEW INTEGRATION OPERATIONS to be associated with a partition of the set of instances of EMPLOYEE. In the integrated view View Integration operations permit the the partitioning association includes EMPLOYEE- merging of user views to develop a Global View. TYPE partitions from View 1 enhanced by Operations are performed on targets of integra- EMPLOYEE-TYPE partitions from View 2. Mutual tion namely, object types and connector types. exclusivity must be obeyed, otherwise partition One operation on a target of integration may enhancement is disallowed. In this example an trigger several operations with the object and EMPLOYEEinstance must map into one of the four connector types which were involved in the partitions defined b.y the four instances of View integration former operation as targets. EMPLOYEE-TYPE.

Proceedings of the Eighth International Conference ols very Large Data Bases 149 MsxicoCity,G&embr,1982 Partition Addition is the addition of a new aartitioninq association for a given entity tvne. In the above example of EMPLOYEE-TYPE partitions, if the partitions from two views cannot be disjoint (e.g. a Nurse can also be a Surgical-assistant), then the two EMP-TYPE-SEL partitionings need to be kept separate in the inteqrated view. From any single preferred view's standpoint, this amounts to adding a new Conflict in connector tvpes calls for partitioning association to that view. desiqner intervention.

Subset Addition is the addition of one or more subsets to an existing association to allow 5. CONFLICTS IN VIEW INTEGRATION a different subset of association instances to be a named subset. Figure 15 illustrates subset Conflicts in the integration process arise addition. The integrated view shows the five during the matching and integration of views for association types which are subsets of the several reasons. They are presented to the association type DRUG-SCHEDULEfrom View 1 and designer for resolution. If the designer is View 2. able to resolve them (possibly with the help of users) integration continues with the new information; otherwise the conflict is added to the 4.3.2 ATTRIBUTE TYPE OPERATIONS set of unresolved conflicts. Conflicts may partly be caused b.v incomplete or erroneous Attribute Enhancement is the addition of specification of input and partly due to differ- new attribute types to an object type to account ences in modelinq. Conflicts may be classified for the partial match or mismatch of that object by considerinq their source into the following type with other views. Fiqure 10 shows how classes: attribute enhancement is applied to the entity type DEPARTMENT. Considering that each view a) Object descriptions, includinq naminq contributes instances of an entity type, the and dependency conflicts attributes which are not present in a particular b Equivalent View conflicts view are supposed to be given null values in the C Modelinq conflicts integrated view.

Attribute Creation is an operation where a 5.1 OBJECT DESCRIPTION CONFLICTS new attribute is created in an object tvoe._ to convey the same information as is contained in These can occur in the form of synonyms another view by means of a categorization or (different names referring to the same objects) partitioning association. Fiqure 16 shows an or homonyms (one name referring to different example where object-type STUDENT is being ob.jects). In the proposed matching scheme matched in two views. To convey the categorita- synonyms will cause a complete match on key and tion information about a STUDENT, a new non-key attributes but no match on name; and attribute called Category is created in the .homon.vms will be shown up b,v a condition where integrated view. The value set for Category two objects have the same name but the ke.y and will be assigned (by the designer); e.g., non-key attributes do not match completely. In Category = 0 for graduate, 1 for undergradu- either case, our current implementation scheme ate. Note that the attributes, Degree and Rank, requires designer confirmation before any merg- which are a part of the entity type GRAD-STUD ing of object types is attempted. A designer 'and UG-STUD are used for an attribute enhance- should allow two object types, whether with the ment of STUDENT. same name or different names, to be integrated (merged) only after ascertaining that they have the same set of instances. A wronq choice of 4.3.3 CONNECTORTYPE OPERATIONS name could cause the reportinq of more conflicts as additional views are inteqrated. Restriction is defined as the-selection of the most restrictive connector specification for As discussed previously, several dependency representation in the integrated view. Connec- conflicts may occur. These conflicts are gener- tor types show three types of dependency: ally resolved by adopting the most restrictive ownership, deletion and null dependency. When specification out of those in different views merging two views the combinations of dissimilar and then providing mapping rules wherever necei- connector types may be integrated as follows: sary for individual views. One case where the

Proceedings of the Eighth International Conference 150 on Very Large Data Bases Mexico Cii, September;‘7982 conflict cannot be resolved (see Restri' ction 6. CONCLUSIONS Operation) is when the same object is an owner of association A in view 1 and is del' etion We are currently implementing a design aid dependent on association A in view 2. which allows user views to be input using the N- S model, builds a dictionary of views and performs view integration using the approach 5.2 EQUIVALENT VIEW CONFLICTS described above. Emphasis is being placed on desiqner interaction and ouraim is to produce a The integration process assumes that equiv- workable solution for dealing with large prob- alent views will be accompanied by inter-view lems of integration which designers cannot cope assertions stating equivalence. When equivalent with manually. views are not accompanied by inter-view assertions, the integration process cannot detect The conclusions of our investigation into equivalence and hence yields redundancies of the view integration process are as follows: data. In addition, partial match conditions may be detected and the designer warned of possible a) The success or failure of view inteqra- conflicts. Figure 6 shows two views which are tion is largely dependent on getting as explicit equivalent. However, without. an inter-view a statement of user views as possible. The job assertion about equivalence, the integrator will of extracting all relevant information from each report that object-type DEPTS from View 1 user (or user group) is a major challenge to the partially matches with DEPTS as well as with designer. It is not clear whether the designer MEDICAL, SURGICAL, etc. from View 2. The con- should do an ad hoc analysis of user views to flict may arise whenever no equivalence is detect equivalences (e.g. restructure equiva- stated by an assertion, yet there is a total lence) and then try to specify them on his own match or a partial match among either key or or whether he should expect different user areas non-key attributes which indicates a possibility to know of the similarities and differences in of equivalence. This signals an equivalent view their data needs. conflict and warrants designer intervention. b) From the detailed discussion of object and connector matching it is clear that the task 5.3 MODELING CONFLICTS of matching and integrating views represented by objects and connectors is non-trivial. Differences in representation of views can Decisions made in the automatic View Integrator potentially lead to redundant data after inte- should be confirmed at every step and the gration. However, genuine cases exist where the designer/user should bring in his instance same situation may be modeled differently by level knowledge about data to evaluate the different users. Figure 17 illustrates a model- matches or mismatches. User help may be sought ing conflict involving the use of partitioning from time to time to guide this process. and categorization associations. The instance implications of Views 1 and 2 are drastically c) In the conflict resolution area, consi- different, Consider the following situation. derable human involvement is necessary. It is Entities 'of type PATIENT are partitioned in two possible to classify conflicts and help the user ways in View 1: by admission status and b.v age- in an understanding of the conflict, but the group. ADMISSION-STATUS is an entity type with ultimate repsonsibility to resolve them will be two instances and so is AGE-GROUP. In View 2 up to the users and management who set policies. the infbrmation about patients is more detailed - there is an instance of one of the category d) Given that users are kept actively/ types INPATIENT or OUTPATIENT for every PATIENT; interactively involved in the view integration similarly there is an instance of category types effort, the main advantage a machine can provide PEDIATRIC or ADULT for every PATIENT too. To. is to deal with a large number of integration support both views, the designer must allow the alternatives and present them to the user. An categorization association as well as the parti- automated or semi-automated approach is still tioning associations to be preserved. beneficial when the volume of comparisons of data names and data characteristics is too high Between the conditions of a complete match to deal with manually. The actual view integra- and a complete mismatch of objects we have a tion operations at the object and connector range of partial matches. Table 1 shows the level were shown to be straightforward and can match conditions when matching on Object names, be easily automated. key attributes and non-key attributes. An integrator nust provide for a set of actions in The overall conclusion from the above, each of those cases. therefore, is that a View Integrator can be a

Proceedings of the Eighth International Conference 151 on Very Large Data Bases Mexico City, September, 1982 valuable aid in design for realistic important concept in the model and provide some “integrated“ databases used in most organiza- explanation. References are made to the tions. It is however futile to expect that such examples used in the bod.y of the paper. a system could solve the problem completely on its own and produce a tailored design of the database. The system has to be an interactive Terminology one where the user/designer team will navigate the course to an acceptable design. An entity ty e refers to a physical thing, object, &son document etc whose existence is of inte:est to tke usi'r. An ACKNOWLEDGEMENT association type is an n-ary relationship among n object types. An object type is either an The authors wish to thank Melanie Smith for entity type or an association type. An her comments on an earlier version of the paper. association type is .a fact, a concept or a Discussions with Maurizio Lenzerini of the relationship among its components. University of Rome have been useful. This work was supported in part by DOE grant No. DE-ASOS- Each object type has a descriptor set which 81ERl0977. is a list of attribute types used to describe the object type. An attribute type may' be atomic in which case it is a propertv. aualitv APPENDIX: or characteristic of the object types-which it can describe. Otherwise, an attribute type may View modeling in the Navathe-Schkolnick Model be defined as a list of other attribute types. The attribute type structure within an object This appendix describes the essentials of type can thus be hierarchically orqanized and is the View Representation model [ll] which was shown by a nested parenthetical notation (e.g. introduced as a vehicle for expressing the views see Figure 4). of data held by user groups or individual users of a database prior to its design. Most of the A connector type shows the linkage or the terms used below are identical with those in logical access path among two object types where c111. Some terminology has been changed to one of them is an association type and the other improve claritiy and understandability. The is a participant in that association type. A reader is referred to [ll] for a comprehensive connector type, if undirected, is represented by discussion about the model. a two tuple. When directed it is represented by an ordered two tuple. An assertion is a statement (in some assertion specification General Description language) which describes a specfic relationship among instances of object types from one view or The model expresses a user's view of data multiple views; the term intra-view and inter- by employing the following type constructs: view assertions are used correspondingly. entity, association, attribute, connector. Assertions are used when the semantics of the These types are divided into subtypes as shown directed connectors is inadequate to model in Figure 2. Assertions are used additionally instance interdependencies. to state interrelationships and constraints which cannot be otherwise expressed. The term A list of key attribute types of an entity object type is used to stand for either an type provide a .total identification to it when entity type or an association type. In general, each instance omnique value the model allows the user to start with the list of the ke.v attribute types. Such entity entity types of interest, describe each entity types are called self-identified. Partial type with a nested list of attribute types and identification of an entity type by its build any number of levels of association types. attributes implies the need for external identi- No instance information is captured in a view fication. External identification is defined as diagram besides that in the form of assertions. the process of augmenting the partial internal identifier (p1D) of an entity with the key The model provides conventions for a visual attributes of other objects. E.g., in Fig. 8, description of a user view. This visual CHIEF has a key attribute Chiefname (key- description, called a view diagram, is in the attributes are always underlined in view form of a graph with object types as nodes and diagrams) which is a partial identifier. CHIEF connector types as edges. Assertions are not is externally identified from entity type LAB. graphically represented. The model allows an object type to have several external identifications. The semantics of the model include rules of insertion and deletion at both the type and Association types are divided into two instance level. Some of them are covered below subtypes: simple and identifier. An identifier and in Fig. 3. In the following we define each association is an n-ar.y association which

Proceedings of the Eighth International Conference on Very Large Dete Beses 152 Mexico Citi, Seqtemk, 1962

J _ provides external identification to uniquely entity types. Lack of directed connectors in a identify an instance of a partially identified simple association implies that there is no object type from the remaining (n-l) objects specification of the ownership of the associa- types. An association is called a simple tion nor of any deletion dependency. Fig. 3 association if it is not an identifier associa- shows the above possibilities and explains the tion. (See [8] for a detailed discussion of insertion/deletion rules. In an identifier identification of data). association type a directed connector tvoe points to the entity type which is identified by the rest (see Fig. 8). Diagrammatic Notation Three special types of simple associations The visual description of a view is real- are defined: ized in the form of an acyclic graph called a view diagram where object types are nodes and 1. categorization is an n-ary relation connector types are edges. All of the concepts between an owner object type and member mentioned above, except intra-view assertions, object types called category t,vpes. are used in the view diagram. Object types !;xc;;;,identifier association) are represented, 2. partitioning is a binary relation among In the view diagram, association object types; an instance of the object types are'grouped on one side of the diagram and We which causes partitioning is entity types are grouped on the other. Object associated with a set of instances (a types are described by descriptor sets within partition) of the other object type. the diagram underneath the object type if possible. A self identified object type is 3. subsettinq is a unar.y association over represented by placing a # symbol next to the an object type. object type in the view diagram (e.g. SERVICE in Fig 18). An identifier association is repre- Cateqorization A of an object type X into sented as a rectangle with undirected connectors objet ttypes . ..X is denoted by an from the identifying object type(s) to the iden- association ty& AP i,, X2"1 . ..X ) which is tifier association and a directed connector from marked "cat" in a view diagram. Ffqures 12, 13 the identifier association to the identified show examples of categorization. Categorization object type. A implies that there exists a mapping f which maps every instance of X into a subset oP categories XI, X2, . ..X.. Simple Association Type A binary partitioning association type A simple association type is a way of S(X,Y) associates an instance of X with a subset relating instances of one object type with of the instances of Y. Typically, X and Y are instances of another object type, The content entity types but either one or both may be asso- of a simple association contains tuples composed ciation types. Partitions of the instances of Y of the total internal identfiers TIDs) of all are non-overlapping, such that each partition object types involved in the assoct- ation type, has a different instance of X associated with it as well as any attribute types describing the via S. A partitioning association is marked simple association type. This type of associa- "partition" in a view diagram. tion is represented with undirected connectors between the objects (involved in the associ- Mathematically, ation) and the simple association. Identifica- tion of simple association types is achieved by let Iy be the set of instances of Y. concatenating the TIDs of all of the object types involved in the association type. There 2'y denotes the power set of Iy, is no restriction on the number of simple association types that an object type can be i.e. the set of all its subsets. involved in. Then there is a function G, associated with S: Directed Connector Types Directed connector types express different Gs: Ix + 2Iy, such that kinds of dependence among object types to which they relate. In an n-ary simple association there is a directed connector from an entity to IY = iCl Gs(xi) the association if it plays the role of an Owner of the association. If deletion of the associa- and Gs(Xijn Gs(Xj) = * for i f 5, tion implies that certan entity instances get deleted, this is also indicated by a directed where XI x2 . ..xm are all instances of X. conector type from the association type to those

Proceedings of the Eighth International Conference on Very Large Data Bases 153 Mexico City, Septemkr, 1geZ The partitioning association EMP-TYPE-SEL in the 1971 ACM-SIGFIDET Workshop on Data View 2 of Figure 14 implies that the instances Description, Access and Control, Ann Arbor, MI of entity type EMPLOYEEare partitioned into 2 May 1974. sets. One is associated with the first instance of the entity type EMPLOYEE-TYPE representing 5. El-Masri, R., and G. Wiederhold, "Data surgeons,' the other with the second instance of model integration using the structural model", the entity type EMPLOYEE-TYPE representing Proceedings ACM SIGMOD International Conference, surgical assistants. Boston, MA, June 1979, pp. 191-202.

A unary subsetting association type T(A) 6. Kahn, B.K., "A method for describing provides a means of givfng the name T to a'sub- information required by the database design set of the instances of A. In the view diagram process", Proceedings such an association is marked "sub". A is typi- tional Conference on Management-of Data, June cally another association type (e.g., DRUG- 1976, ACM, New York. SCHEDULE in Figure 15) but could also be an entity type. There is no mutual exclusiveness 7. Lum. V.Y. et al.. “1978 New Orleans constraint among the subsets of instances of A data base design working report", Proceedings of defined by subsetting associations TI(A), T2(A), the 5th International Conference on Ver.y Large . . . . etc. Data Bases, Rio de Janiero, Brazil, October 1979, pp. 328-339. View Representation using the N-S model is illustrated with the example in Figure 18: The 8. Navathe, S.B., "Schema analysis for figure shows six entity types: SERVICE, database restructuring", ACM Transactions on PROCEDURE, SCHEDULE, PERSONNEL, INPATIENT- Database Systems, 5, 2, June 1980. PROCEDURES,OUTPATIENT-PROCEDURES; an identifier association PROCEDURE-IDENTIFIER which identi- 9. Navathe, S.B., "An intuitive procedure fies instances of SERVICE with instances of to normalize network structured data", Proceed- PROCEDURE;a simple association type PERFORMED; ings of the 6th Very Large Database Conference, the categorization association PROCEDURE- Montreal, Canada, October 1980, pp. 350-358. CATEGORIES which categorizes PROCEDURE.into INPATIENT-PROCEDURES and OUTPATIENT-PROCEDURES 10. Navathe, S.B., and J.P. Fry, "Restruc- and subsetting association types PERFORMED-FREE turing for large databases: three levels of and PERFORMED-REPEATEDLY.The figure also shows abstraction", ACM Transactions on Database with directed connectors that the object type Systems, 1, 2, June 1976. PROCEDURE is identified by .association type PROCEDURE-IDENTIFIER, and owns the categoriza- 11. Navathe S.B., and M. Schkolnick, "View tion PROCEDURE-CATEGORIES,and that the entity representation in logical database design", type SCHEDULE is deletion dependent on the Proceedings of the ACM-SIGMOD International Con- association type PERFORMED, PERFORMEDis shown -ference, Austin, TX, Junea.;I9!?, ACM, New York. to be the owner of the subsetting association types T 12. Raver, N. and G.U. Hubbard, "Automated logical database design: concepts and applications", IBM Systems Journal, No. 3, 1977.

REFERENCES 13. Smith, J.M. and D.C.P. Smith, "Data- base abstractions: aggregation and generaliza- 1. Arora, A.K. and Robert C. Carlson, "The tion", ACM Transactions on Database Systems, 2, information preserving properties of relational 2, June 1971. database transformations", Proceedings of the 3rd Very'Large Database Conference, Berlin, West 14. Teichroew, D. and E.A. Hershey, III, Germany, Ittt, 1978. "PSL/PSA: A computer-aided technique for struc- .tured documentation and analysis of information 2. Batini, C., M. Lenterini and G. processing systems", IEEE Transactions on Soft- Santucci, "A Computer-aided Methodology for ware Engineering, Vol. S.t-3, No. 1, January ,Conceptual Database Design", Information 1977. Systems, Vol. 7, No. 3, Pergammon Press (to 'appear). 15. Weldon, J.L., "Integrating database logical views", Unpublished Working Paper, New 3. Chen, P.P.S., "The entity-relationship York University, 1979. model: towards a unified view of data". ACM Transactions on Database Systems, Vol. 1, ho7 16. Yao, S.B., S.B. Navathe, and (March 1976). J.L. Weldon, "An integrated approach to logical database design", Proceedings of the NYU Sympo- 4. Codd, E. F., "Normalized data baSe sium on Database Design, May 1978, [in 171; structure: a brief tutorial", Proceedings of

Proceedings of the Eighth International Conference on Very Large Data Bases 154 Mexico City, September; l-982 17. Yao, S.B., S.B. Navathe, J.L. Weldon, T.L. Kunii [eds.], Database Design Techniques I: Requirements and Logical Structures, Springer Verlag, New York, 1982.

Proceedings of the Eighth International Conference on Very Large Data Bases 155 Mexico City, September, 1982

~~~_ I I Information Processing Structure(lS) Requirements (PR)

User View, Ehterprise View

Global Model

Logical Functional DBMS Design of SChpi3 Applications

t t Physical Detailed DBMS Transaction Schema Processing

Fig. 1: Conceptual Framework for Database Design [ll]

attribute

/ObiO\association entity directed/ LLted connector connector /\ aAyg?on ;~$&

categorization ’ partitioningI \&e*ing

Figure 2: The Type Hierarchy in the View Representation Model

Proceedings of the Eighth International Conference on Very Large Data Bases 156 Mexico City, September; 1982 Airthe-cbjectty~inassohtii tvp B. C and D an “owner dqmncbnt” on A. (iI instances of A can be frmly in-. (ii) instanar of C or D annot ba insermd u”lCS suodatd with mm8 A. (iii) if an instance u of A is d&ted, its its anociatiin instances in 6 a. .<(*. bb, cc>containing u am also Ill leted; instancaofCuldofDwldchwa not refermad in any other instant of B an also d&tad.

Debtion Dapmdmq DiSthOmankrObjscttypin8WCi4tii tvp c. D b “daktiin &pandmt” on C and E. Dalatiin of n instance cc of C implies C E wtomatic &lotion of the amxiaal 0 imtanaddofD,rubjucttotwocondi- ..c tii”S: ------: i- - -- (i) ~~tio;cxwnnwmt of any other *t . (ii1 dd is not a componmt in anothat asswiation instance (differant from C, 73D Slldl~E~

Null Dapmtd~q No ownership and no deletion depabncy fwwociation(ypeFandrmongobjact twms E and 0. F Implies that E and G on b frnhl inwtad and &lomd.

------

E G

cl%Fig. 3: Diiemnt Typm of apandencia

A - h. b. (c. dl. (e, (f)l) a, b, c, d, ., f w l ttrii m. lh”omtio”o”umbftlhomeNir natal rtructu~ withii w-typa A. Clmton such ill (cd) mq have thdt OW”“8”lSS.

Fig. 4: Vii Repmmtation with N-3 maW thawing npmmtbn of amity-types from assacinbn tvpl l d . hiuuchy of atwlbum typa within an mtity

huisHi&. Srvico-Nam. Typ) mavi~No., a&a&m, Typo)

Fii. 6: R wnmnmtkmEquivafana-&mob&ctsintwo v*mbutwitbdiffaantprinnLyr.

Proceedings of the Eighth International Conference on Very Large Data Bases View 1 (7CONTAINS

(Dept-No., Dept-name, Dept-type, Budget)

bntername, City) (Dept-No., Dept-name) (Budget) (Budget) (Budget)

Fig. 6: Restructure Equivalenw

Enterprise Local Intra-view Interview View Views Assertions Assertions

Integrator

1 :iq, i..:,. ,>it

Fig. 7: A Model for View Integration

Proceedings of the Eighth International Conference 158 on Very Large Data Bases Mexico City, September, 1982 LAB-CHIEF I IDENTIFIER I

Lab-No., ,Lab-Name Type) , (Chief-Name, Title) Building-Name, Floor 34

(Lab-No.. Lab-Name, Type) (Lab-NameA-, Chief-Name Title) (9uildin9-Nwnq %#I

Fig. 9: Normalization of Idantifiw Associations

View 1 (CONSISTS-OF\ (Preferred)

(DivNo,-- DeptNo, LOCI

View 2 (@AZ) (+zz-- WeptNo, Lot)

(e-j (ii&h&) (-&-i&-j (DivNo, DeptNo, Lot)

F@ 9: lntsgation of vials when them is a complete match on name, partial match on key attributes and complete match on non-key attributes.

Proceedings of the Eighth international Conference 159 on Very Large Date Bases Mexico City, September, 1982 View 1

Integrated View

(CenterName, City) WeptName, Sire) --- f -- View 2 (Preferred)

(DeptNo., DeptName, Lot, Size) (OEP/\RTMENT)(G] (DeptNo., Lot)

Fig. 10: Integration of views when there is a complete match on name, no metch on key or non-key attributes.

View 1 (Preferred) s=?MAINTAINS ----f---t-- (CLINICAL-UNIT)(NURSESTATION) (w, Flood, Matronname)

(CLINICAL-UNIT)(W) (E&&g Unit-name, Heed-nurse-name)

Integreted View: Same as View 1

Fii.11: lntegretion of views with object types having different names.

Proceedings of the Eighth International Conference on Very Large Data Bases 160 Mexico Cii, Sf1ptembm;-~W82 (Room Q Admissiondate) (Date-last-visit)

;gjsii?;(Immuniz-cod4 (BPhigh, BPlow)

Integrated View

Fig. 12: Categorization Addition

lntegmted View

Fig. 13: Category Enhancenttmt (type dim)

Proceedings of the Eighth International Conference on Very Large Data Bases 161 Mexico City, September, 1962 :

.__-__~ .~-~ i V*rr 1: Medial Smio Empkwm

partition.

Intapatd View: Ydiol and Surgical Employrr

partition. EMP-TYPE-SEL

Fii. 14: Putiiion Enhm-t Mow immca of an ntity type afled EMPLOYEE-TYPE)

rub. sub. rub. O.D. B.I.D. T.I.D.

I/ y*rrl DRUG SCHEDULE

PATIENT DRUG

sub. sub.

KAY: O.D. = Ona , day E.I.D. = Twice . dam T.I.D. - Thrr rimes a dq O.I.D. - Four times a dy PRN = Talc. m mqui,.,,

ub. sub. sub. rub. sub. E.I.D. T.I.D. D.I.D. PRN

l/g2 DRUG-SCHEDULE

DRUG

Fig. 16: SubsM Addition ItYP dim)

Procwdings of the Eighth International Conference 4Mr‘very Large Data Bases 162 wt. View 1 ST-CATEGORIES ggg2y-&;\ STUDENT = (SS#i GRAD-STUD = UG-STUD = (Rank) Name, Grade-pt-avg.) (Deer4

Interview constraint: s < STUDENT = is. g. - > 6 ST-CATEGORY pB (s. -, u > t ST-CATEGORY (mutual exclusion)

View 2 (preferred) (STUDENT) STUDENT = ($j& Name, Grade-pt-avg.)

Integrated View STUDENT

STUDENT = (E+ Name, Grade-pt-avg., Category, Degree, Rank)

Fig. 16: Creation of a new attribute type called ‘Category’ during integration.

View 1 (Higher Administration View)

\~ --/ . / (Status-type, Total-no., (Gro~iads, Capacity)

View 2 (Operational View)

Fig. 17: Two different views of patient information; which may coexist.

Proceedings of the Eighth International Conference al Very Large Data Bases 163 Mexico City, SW&amber, Q#@2 - ___

sub., sub. f PERFORMED- \ f PERFORMED- \ FREE \ REPEATEDLY /

PROCEDURE- IDENTIFIER

Entity Types SERVICE (Service-Name, Location) PROCEDURE (Procedure-No., Procedure-Name, Type) PERSONNEL (Emolovee-No., Employee-Name, Title, Sex) SCHEDULE (Qg&, Time-start, Time-finish) INPATIENT-PROCEDURE (Labname) OUTPATIENT-PROCEDURE (Outpatient-unit-no.)

Association Types PROCEDURE-IDENTIFIER (identifier-association tvoe). . PERFORMED PROCEDURE-CATEGORIES fcategorizationessociation type) PERFORMED-FREE (subsettingessocietion tvpa) PERFORMED-REPEATEDLY (s&setting-association tvpa)

Fig. 18: View Representation using the NS model.

Pkceedings of the Eighth International Conference on very Large Data Bases 164 Mexico City, September, 19S2