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 "com-
munity 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 <s,p> e PROCEDURE-IDENTIFIER &
description of the model and its advantages <p,c,r> E PERFORMED ==>
follows. <p,c,r> 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 charac-
teristics 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 indi-
vidual 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 deal-
ing 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 integra-
tion equivalent views. The inter-view asser- tion process may be described as follows.
tions for Figure 15 are:

1. View 1 = REP[View 21 Inputs

'_.

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 such
l ** thatvn each
into 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 asser-
tions. 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 PLACE-OF-ORIGIN)
l entity types NURSE-STATION and RECEPTION-
= 'US' ,' EUROPE','ASIA','OTHER' STATION. However, an inter-view assertion
(possibly input by the designer after ascertain-
ing 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 SUBVIEWOR 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 similar-
ity 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 Mexico City, September, 1982
on Very Large Data Bases
 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
5 new categorlzatlon of an entity-type. Figure 12
Deletion Null
6 Ownership Deletion Conflict shows the integration of two views with differ-
ent categorizations of the same object PATIENT.
The integrated view is obtained b.y merging the
Combinations 1, 2 and 3 represent condi-
tions 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-
The latter method is chosen in keepinq either type PEDIATRIC or type ADULT.
da cy.
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 gorization addition is preferred.
for Combinations 4 and 5 will include the more
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 Partition enhancement is illustrated
ciation.
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- Mutual
EMPLOYEE-TYPE partitions from View 2.
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
former operation as targets. View integration
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 infor-
mation; 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 CONNECTOR
TYPE 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 Mexico Cii, September;‘7982
on Very Large Data Bases
 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 asser-
tions, 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& APi,, 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 cate-
gories 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-SIGMODInternational 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 applica-
tions", 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

~~~_
 Information
I I
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\
entity association /
directed
connector
LLted
connector

/\
aAyg?on ;~$&

categorization ’ partitioning
I \&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

73
0 imtanaddofD,rubjucttotwocondi-
..c tii”S:
--- ----: (i) ~~tio;cxwnnwmt of any other
i- - --
*t .
(ii1 dd is not a componmt in anothat
asswiation instance (differant from C,
D 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

cl%
and &lomd.

---- ---- ---

E G

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 ld . 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

(7 CONTAINS

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

View 2

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
 I LAB-CHIEF
IDENTIFIER I

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

(Lab-No.. Lab-Name, Type) (Lab-Name

A-, 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)

----f---t--
s=?MAINTAINS

(CLINICAL-UNIT)
(NURSESTATION)
(w, Flood,
Matronname)

View 2

(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)

View 2

;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
Name, Grade-pt-avg.)
GRAD-STUD = UG-STUD = (Rank)
(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