Download A Methodology of A Database Schema Design Using

A Methodology of A Database Schema Design Using The Subschemas
Ivan Luković
Sonja Ristić
Pavle Mogin
University of Novi Sad,
Faculty of Technical Sciences
Novi Sad,
Serbia and Montenegro
Business College Novi Sad
Novi Sad,
Serbia and Montenegro
Victoria University of Wellington,
School of Mathematical and
Computing Sciences
Wellington, New Zeland
[email protected]
[email protected]
[email protected]
Abstract. The initial assumption is that a database schema is
produced by the integration of simultaneously and independently designed subschemas. The notion of a subschema is
defined using the concepts of the relational data model, according to the appropriate external schema, which is used to
express a user view onto a future database, on the conceptual
level. The process of simultaneous design of subschemas usually may lead to the collisions in expressing the real system
constraints and business rules. If these collisions exist, some
of the subschemas are not consistent in a formal sense with
the database schema, which is obtained by the integration of a
set of subschemas. The programs made over the inconsistent
subschemas do not guarantee safe database updates. The aim
of the paper is to present a process of a database schema
design using the subschemas, that assure the design of the
consistent subschemas and formally correct database schema.
A common algorithm for checking of the constraint consistency between the database schema and subschemas, on the
level of the same constraint type, is presented too.
I. INTRODUCTION
Some of the main problems of a database schema design
are: i) how to define a set of attributes and a set of constraints that faithfully represent a real system and its business rules; ii) how to apply the complex techniques of a
database schema design; and iii) how to overcome the
limited perception power of a designer, when a real system
is too complex. In order to relieve these problems or even
overcome them, it is necessary to apply a methodological
approach. A methodology of a database schema design
using the subschemas is presented in the paper.
After the identifying of groups of similar end users business tasks, for each of these groups, an external schema is
designed, as the first step of a database design process. An
external schema is based on a data model, which is convenient for the conceptual design. [2].
It is difficult and sometimes even impossible to formalize the process of integration of external schemas. The
quality of the resulting database schema highly depends on
the designer's knowledge and skillfulness. On the contrary,
a process of the integration of subschemas in the relational
data model can be formalized and automated on the basis
of the synthesis algorithm [2].
A subschema is defined by means of the concepts of the
relational data model. It is designed using the appropriate
external schema. By an integration of a set of subschemas,
the potential database schema is created. If the collisions
in expressing the real system constraints and business rules
exist, between some subschemas, some of the subschemas
are not consistent with the potential database schema in a
formal sense.
The subschema is a part of the transaction program
specification. It represents a data structure over which a
transaction program is executed. Operations of a transaction program should be executed against a database, directly. To allow safe database updates by a program made
over the subschema, the subschema itself has to satisfy the
conditions of the formal subschema and database schema
consistency. The using of programs over the inconsistent
subschemas may lead to logically incorrect database updates. One of the aims of the paper is to propose that the
presented methodology of a database schema design can
assure the design of the mutually consistent subschemas
and formally correct database schema.
The consistency conditions may be expressed for each
type of constraint, separately. The paper also presents a
common algorithm for the detection of constraint inconsistencies between the database schema and a subschema,
on the level of the same constraint type.
Apart from the Introduction and Conclusion, the paper
has five sections. Section two formally introduces the notion of a subschema. Section three describes the principles
of a database update using subschema concepts. The formal consistency conditions are presented in section four.
Section five is concerned with the integration of subschemas, while a common algorithm for the detection of inconsistencies is presented in section six.
II. THE NOTION OF A SUBSCHEMA
A relational database schema is a pair (S, I), where S is a
set of relation schemes and I is a set of interrelation constraints. It is supposed in the paper that the database
schema is produced using a well-defined methodological
approach.
Each relation scheme from S is a named triple: N(R,
C, Kp(R)), where N is a unique name, R is an attribute set,
and C is a specification of constraints. A relation scheme
will be often referred simply by its name N. The specification of constraints C is a triple (K, τ (N), Uniq(N)),
where K is a set of keys, τ (N) will be called tuple integrity
constraint, and Uniq(N) is a (possible empty) set of
uniqueness constraints Unique(N, Xi), where Xi is a proper
subset of R, which does not contain any key from K. The
tuple integrity constraint is a pair τ(N) = ({τ(N, A) | A∈
R}, Con(N)), whose first component contains attribute
domain constraints τ(N, A) of each attribute A∈R. Each
τ(N, A) is of the form τ(N, A) = (Dom(N, A), Null(N, A)),
where Dom(N, A) is a domain constraint of attribute A∈R
and Null(N, A)∈{⊥, T} is a null-value constraint of A∈R.
The second component of τ(N), Con(N) is a logical expression defined over the attributes from R and their domain
values. It must be satisfied by each tuple from an instance
over N. A uniqueness constraint Unique(N, Xi) means that
each non null value of Xi must be unique in a relation over
N. More details concerning the specification of constraints
C may be found in [1]. Kp(R)∈K denotes the primary key
of the relation scheme N. The interrelation constraint set I
may contain various types of constraints, of which frequently used referential integrity constraint is just one.
An external schema is a formal and abstract definition of
data and constraints that are needed to make a transaction
program aimed at supporting the implementation of the
end user business tasks. It is based on a conceptual data
model, like ER model or a model based on the form types
[3]. The external schemas are designed simultaneously and
independently by a number of designers.
On the basis of each external schema, the appropriate
subschema is designed, using the relational data model. It
consists of a set of relation schemas and a set of interrelation constraints. Each relation scheme of a subschema
consists of a set of attributes and a set of local constraints.
A role and a set of modifiable attributes are also assigned
to each relation scheme.
Formally, a subschema is a named pair Pk(Sk, Ik), where
Pk is a subschema name, Sk is a set of relation schemes, and
Ik is a set of interrelation constraints. The set of relation
schemes of a subschema Pk is
Sk = {Nik(Rik, Cik, Kp(Rik), Role(Pk, Nik), Mod(Pk, Nik)) |
i∈{1,..., n}},
where Nik is a scheme name, Rik is an attribute set, Cik is a
specification of relation constraints of the form (Kik,
τ (Nik), Uniq(Nik)), where Kik is a set of keys, τ (Nik) will be
called tuple integrity constraint, and Uniq(Nik) is a
(possible empty) set of uniqueness constraints
Unique(Nik, Xik), where Xik is a proper subset of Rik, which
does not contain any key from Kik. The tuple integrity
constraint τ(Nik) is a pair, whose first component contains
attribute domain constraints of each attribute A∈Rik. The
second component of the pair is a logical expression defined over the attributes from Rik and their domain values.
Kp(Rik) is a primary key. The brief explanation of the relation constraint specifications is beyond the scope of the
paper, and it can be found in [1], [2] and [3].
Role(Pk, Nik) is a set of relation scheme roles and defines
the operations that may be performed on an instance of the
relation scheme Nik. Only these operations may be built
into a transaction program made using the concepts of a
subschema Pk. A set of relation scheme roles is a nonempty
set, for which Role(Pk, Nik) ⊆ {r, i, m, d} holds, where: r
stands for data reading, i.e. referencing, i for insert, m for
modification and d for data deleting.
A subschema Pk is intended for database querying only
if (∀Nik∈Sk)(Role(Pk, Nik) = {r}) holds. Otherwise, it is
intended for updating, and querying.
The set Mod(Pk, Nik) contains those attributes of the relation scheme Nik that may be modified. If m∈
Role(Pk, Nik), then Mod(Pk, Nik) must not equal ∅.
A subschema is a part of a program specification. The
transaction program specification should be designed in a
way to provide a development of a functionally correct
transaction program. More information concerning the
notion and the role of a subschema may be found in [1],
[2], [3], [4] and [5].
Example 1. Let subschema P1 is associated to a business process whose task is to control domestic orders. It is
aimed for entry of domestic orders and shipments within
one transaction. In this process, users are not interested in
customer data except in customer id. The specification of
subschema P1 follows.
S1 ={Order_d_s(R11, C11,...), Shipment(R12, C12,...)};
• R11 = {OrdId, OrDate, CustId, Origin, Total};
• C11 = ({{OrdId}}, τ( Order_d_s), ∅),
• Kp(R11) = {OrdId};
• R12 = {ShipId, OrdId, ShipDate, ShipTotal};
• C12 = ({{ShipId}}, τ(Shipment), ∅);
• Kp(R11) = {ShipId};
• Role(P1, Order_d_s) = {i, r},
Role(P1, Shipment) = {i, r};
• Mod(P1, Order_d_s) = Mod(P1, Shipment) = ∅;
• I1 = {Shipment[OrdId] ⊆ Order_d_s [OrdId],
Order_d_s [OrdId] ⊆ Shipment[OrdId]};
The domain for attribute Origin in the relation scheme
R11 is dom(Origin) = {d}. Its only one value ″d″ denotes
domestic orders. P1 also contains an inclusion dependency
Order_d_s[OrdId] ⊆ Shipment[OrdId]. These two constraints denote that the process related to the subschema P1
deals only with shipped orders issued by a domestic customer.
A database schema and a subschema contain the following concepts:
URj ;
• A set of database schema attributes: U =
N j ∈S
U Rik ;
• A set of subschema attributes: Uk =
N ik ∈Sk
• Sets of relation scheme attribute sets:
• S = {Rj | j∈ {1,..., t}}, for database schema; and
• Sk = {Rik | i∈{1,..., n}}, for subschema; and
• Sets of constraints:
t
• O = I ∪ ( ∪ C j ), for database schema; and
j =1
n
• Ok = Ik ∪ ( ∪ Cik ), for subschema.
i =1
The sets Sk and Ok determine the set of subschema Pk instances, whereas the sets S and O determine the set of
database schema (S, I) instances.
+
In the paper, O will denote the set of all logical conse+
quences of a set of constraints O and O |X will denote all
+
the constraints from O , which are defined using only the
attributes from X.
III. ON THE SAFE DATABASE UPDATES
A potential database schema is created by the integration of the designed set of subschemas. It is the relational
database schema, which consists of a set of relation
schemes and a set of interrelation constraints. The set of
relation schemes is generated by the synthesis algorithm.
The sets of relational and interrelational constraints are
generated using the appropriate sets of subschema constraints.
The process of simultaneous and independent design of
each subschema may lead to the collisions in expressing
the real system constraints and business rules, in the different subschemas. If the collisions between the different
subschemas exist, then some of the subschemas are not
consistent with the potential database schema in a formal
sense. Consequently, the programs made over the inconsistent subschemas do not allow safe database updates, i.e.
their using may lead to logically incorrect database updates. Accordingly, such a potential schema must not be
considered as a resulting database schema, after the
integration of the set of subschemas. The explanation of
the notion of a safe database update follows.
A subschema is a description of the data of a relatively
small part of the database. Each relation scheme of a subschema may be considered as a view on a single database
relation scheme. Subschema instances are not materialized.
A subschema instance may be obtained as a result of the
applying appropriate join, select and project operations on
a database instance.
A transaction program issues queries and updates that
are executed by a database management system (DBMS).
Let Tk be a transaction program based on subschema concepts, and let T be a transaction program that is equivalent
to Tk, but based on database schema concepts. To consider
database updates initiated by Tk as safe updates, the subschema and the database schema should satisfy the following two conditions at the abstraction level of instances.
1. A unique (hypothetical) subschema instance, named the
corresponding subschema instance, may be produced by
applying the appropriate relational join, project and select operations on a database schema instance; and
2. If an update of a hypothetical subschema instance issued
by Tk would be successful, then T must be committed by
DBMS.
If a subschema is intended for queries only, it has to satisfy only Condition 1.
In the paper, the aforementioned conditions are called
the principles of a database update using subschema concepts. Their formal definition at the abstraction level of
instances is given in [2] and [12]. A subschema that satisfies these conditions is said to be consistent with the corresponding database schema. Let P be the set of subschemas
and let the potential database schema be the result of the
integration of subschemas from P. The potential database
schema, which is consistent with all of the subschemas
from P, may be declared as a database schema.
Example 2. Let us consider the subschema P1 from Example 1, and a potential database schema (S, I). Let S be
the result of the integration of P1 and some other subsche-
mas. The structure of those subschemas is not relevant in
the example.
S ={ORDER(R1, C1,...), SHIPMENT(R2, C2,...),
CUSTOMER(R3, C3,...)};
• R1 = {OrdId, Ordate, CustId, Origin, Total};
• C1 = ({{OrdId}}, τ(ORDER), ∅);
• Kp(R1) = {OrdId};
• R2 = {ShipId, OrdId, ShipDate, ShipTotal};
• C2 = ({{ShipId}}, τ(SHIPMENT), ∅);
• Kp(R2) = {ShipId};
• R3 = {CustId, CustName, CustAdrr};
• C3 = ({{CustId}}, τ(CUSTOMER), ∅);
• Kp(R3) = {CustId});
• I = {ORDER[CustId] ⊆ CUSTOMER[CustId],
SHIPMENT[OrdId] ⊆ ORDER[OrdId],
CUSTOMER[CustId] ⊆ ORDER[CustId]}.
P1 and (S, I) satisfy Condition 1. For each relation scheme N1 from P1, there is a corresponding relation scheme N
from S, such that R1 ⊆R holds, where R1 and R are the
attribute sets of N1 and N, respectively. The corresponding
relation scheme for Order_d_s is ORDER, and SHIPMENT
is the corresponding scheme for Shipment.
Let T1 be a transaction program based on the concepts of
subschema P1, aimed at insertion of tuples into an instance
of Order_d_s. Let T be a transaction program that is
equivalent to T1, but based on the database schema concepts. T is aimed at tuple insertion in an instance of ORDER, that is corresponding to an instance of Order_d_s. T1
allows the insertion of a tuple with any domain value for
the attribute CustId.
Suppose that an instance over Order_d_s is successfully
updated by T1, in such a way that the database relation
CUSTOMER does not contain a tuple with the given
CustId value. However, the set of database constraints
contains the referential integrity constraint ORDER[CustId] ⊆ CUSTOMER[CustId]. The transaction program T would reject the equivalent transaction over the
database instance. Otherwise, this constraint would be
violated. Thus, there is an example of the successful update
of a hypothetical subschema instance executed by T1,
which would not be committed by a DBMS. Consequently,
P1 is not consistent with the potential database schema
(S, I), and (S, I) cannot be declared as a database schema.
IV. THE FORMAL CONSISTENCY
A subschema and a database schema are formally consistent if:
1. The set of attributes, for each subschema relation scheme, is a subset of the corresponding relation scheme attribute set;
2. Each set of attributes X with a unique value property (as
it is defined in [1] and [2]) in a subschema relation
scheme has the same property in the corresponding database relation scheme; and
3. All the constraints that can be inferred from the database
schema and that are relevant for the subschema are embedded into it.
A formalization of the first and the second condition can
be found in [2]. Their satisfying is a prerequisite for the
validation of the third condition, which can be expressed
by the logical implication:
(1)
Ok |= OrPk,
where Ok is the set of all constraints of the subschema Pk,
and OrPk is the set of all database schema constraints that
are relevant for Pk.
The most important components of the specification of a
constraint o∈O are expressed by a set T(o) in the following
way:
V. THE INTEGRATION OF SUBSCHEMAS
A general solution of the implicational problem in the
presence of different constraint types is very hard to find, if
even possible. Testing the satisfaction of the formal consistency may be relaxed by considering the implicational
problem for various constraint types separately. We believe that this approach relaxed in that way, may lead to a
good database schema design practice.
After the potential database schema is created, the automatic detection of the collisions is performed. Then, the
designers are directed to redesign formally incorrect external schemas. The process is iterative. It will stop when the
collisions do not exist any more. The procedure of the
database schema integration is outlined in Figure 1.
T(o) = {(N1, ρ1, At1, {(op1i1, act1i1) | i1 ≥ 1}),...,
(Nm, ρm, Atm, {(opmim, actmim) | im ≥ 1})}.
ij
j, Atj, {(opj ,
Information requests
The specifications (diagrams) of processes and dataflows
actjij)
| ij ≥ 1}), Nj is the
In the four-tuple (Nj, ρ
name of a relation scheme that is spanned by o,
ρj∈{referenced, referencing,...} is the role of Nj in o, Atj is
a set or sequence of attributes from Rj that are relevant for
o, and {(opjij, actjij) | ij ≥ 1} is a set of pairs (critical operation, activity). An attribute A is relevant for o if o is used to
check values of A. An operation opjij∈{insert, delete, update} is a critical if it can violate a constraint and
actjij∈{NoAction, Cascade, SetDefault, SetNull} is an activity for preserving data consistency in an attempt of its
violation.
A constraint o should belong to the set of relevant constraints for subschema Pk(Sk, Ik), if the operation that might
violate o is allowed in Pk.
There are two kinds of relevant constraints:
• The inclusive, denoted by Ini(O, Pk); and
• The extensible, denoted by Exi(O, Pk).
Suppose a constraint o∈O+ is relevant for subschema Pk.
that satisfies Conditions 1. and 2.
The constraint o belongs to Ini(O, Pk) if it can be expressed by the concepts of subschema Pk. It means that for
each relation scheme Nj appearing in T(o) there is a subschema relation scheme Nik∈Sk, such that Rik ⊆ Rj and Atj ⊆
Rik hold.
A constraint o belongs to Exi(O, Pk) if and only if it is
relevant for Pk, and o∉Ini(O, Pk) holds.
Definition 1. A subschema Pk is formally consistent
with a database schema if Conditions 1. and 2. hold, and if
the following conditions are satisfied:
(2)
Ok |= Ini(O, Pk),
(3)
Exi(O, Pk) = ∅.
It is proved in [2] that the formal consistency of a subschema and a database schema is the necessary condition
for the satisfaction of the update principles. It leads to the
conclusion that a database schema design process should
adhere to formal consistency conditions to assure the design of the consistent subschemas and formally correct
database schema.
The set of external schemas
The set of conceptual specifications of
transaction programs and aplications
The set of subschemas
Potential database schema
schema
NO
The set of implemention specifications of
transaction programs and aplications
The formal
consistecy?
YES
Implementation database schema
Internal database schema
The definition of the database schema
and internal schema in DDL
Figure 1. The elements of the database schema integration
VI. AN ALGORITHM FOR THE DETECTION OF
INCONSISTENCIES
A common algorithm for the detection of constraint inconsistencies between the subschema and the database
schema on the level of the same constraint type, named
DCI algorithm, is presented in Figure 2. Ini(O, T, Pk) denotes the set of inclusive relevant constraints, of the specified constraint type T, for subschema Pk, while Exi(O, T,
Pk) denotes the set of extensible relevant constraints of the
type T, for Pk.
Ini(O, T, Pk) contains database constraints that can be
expressed by the concepts of subschema Pk. To each o∈
Ini(O, T, Pk), the function tc(o, Pk) associates a corresponding constraint, expressed by means of the concepts of
the subschema Pk.
THE ALGORITHM FOR THE DETECTION OF
CONSTRAINT INCONSISTENCES
Input:
T,
{OkT | Pk∈P},
OT
A constraint type
OkT - a set of globally valid constraints of the subschema Pk of a given
type T;
P - a set of all subschemas.
A set of database schema constraints,
of a given type T
Output:
Pko, a set of potentially inconsistent constraints
Pksh, a set of triples (Pk, o, A)
Pk - potentially inconsistent subschema,
o - the database schema constraint, causing Pk
being potentially inconsistent,
A∈{T, ⊥}, T – if Pk contains o; ⊥ - if Pk does
not contain o
Error, a Boolean indicator, T – the process of the design has to be stopped; ⊥ the process is going on
BEGIN PROCESS consistency_checking
Pko ← ∅
Pksh ← ∅
DO subschema_checking (∀Pk∈P)
DO ini_constraint_checking (∀o∈Ini(O, T, Pk))
IF tc(o, Pk )∉(OkT)+ THEN
Pko ← Pko ∪ {o}
Pksh ← Pksh ∪ {(Pk, o, ⊥)}
END IF
END DO ini_constraint_checking
DO exi_constraint_checking (∀o∈Exi(O, T, Pk))
Pko ← Pko ∪ {o}
Pksh ← Pksh ∪ {(Pk, o, ⊥)}
END DO exi_constraint_checking
END DO subschema_checking
IF Pko = ∅ THEN
Error ← ⊥
ELSE
DO if_inconsistent_subschema (∀Pk∈P)
DO for_constraint
(∀o∈Pko \ {o∈Pko | (Pk, o, ⊥)∈Pksh})
IF o∈OT|Sk THEN
IF tc(o, Pk )∈(OkT)+ THEN
Pksh ← Pksh ∪ {(Pk, o, T)}
END IF
END IF
END DO for_constraint
END DO if_inconsistent_subschema
Error ← T
END IF
END PROCESS consistency_checking
A database constraint o for which o∈Ini(OT, T, Pk) and
¬(OkT |= o) holds, or o∈Exi(OT, T, Pk) holds, for any
subschema Pk, is potentially inconsistent.
For each potentially inconsistent constraint, the designer
has to decide if it should be embodied into the database
schema.
If the decision is positive, the potentially inconsistent
constraint must be embodied into all the subschemas, for
which it is relevant.
Otherwise, a potentially inconsistent constraint must not
be embodied into the set of database constraints. It must be
emphasized that subschema constraints may be stronger,
but not weaker than the corresponding database constraints. Consequently, some of the subschema constraints
may not be embodied into the database schema.
A subschema constraint is considered as locally valid if
it is embodied into the subschema, but it must not be embodied into a database schema. Subschema constraints that
are embodied into a database schema are considered as
globally valid.
Let us consider a potentially inconsistent constraint and
the subschema into which it has already been embodied as
a relevant one. There are two possible solutions:
• the potentially inconsistent constraint may be excluded
from the subschema; or
• it may be pronounced as a locally valid constraint for the
subschema.
In the first step of the integration process, all subschema
constraints are pronounced as globally valid. In the subsequent iterations some of them may be pronounced as locally valid.
Finally, it can be concluded that there are three possible
kinds of relationships between a subschema Pk and a
potentially inconsistent database constraint o.
• A potentially inconsistent constraint o is not relevant for
Pk, and consequently, Pk is not potentially inconsistent
with a database schema, with respect to o. The designer
need not redesign the subschema Pk, but probably need
redesign some other subschema.
• A potentially inconsistent constraint o is relevant for Pk,
but it is not embodied into the set of subschema constraints of Pk. Pk is potentially inconsistent and the designer may redesign it by embedding o into its set of constraints.
• A potentially inconsistent constraint o is relevant for Pk
and it is embodied into the set of subschema constraints
of Pk, but there is some other Pl, for which o is also potentially inconsistent, but not embodied into it. Pk has
"carried" o into the set of database constraints. Accordingly, Pk is potentially inconsistent. A designer may redesign it by excluding o from its set of constraints or by
pronouncing o as a locally valid constraint for the
subschema Pk.
Figure 2. The pseudo code of DCI Algorithm
A subschema Pk is potentially inconsistent with the database schema if:
(4)
(∃o∈Ini(OT, T, Pk))(¬(OkT |= o)); or
(5)
Exi(OT, T, Pk) ≠ ∅.
VII.
CONCLUSION
The most important advantages of the presented concept
of a database schema design using the subschemas are:
• A set of user requests is divided into the groups of similar end users business tasks to reduce the complexity of
real system and to overcome the limited perception
power of designers;
• For each of those task groups, an external schema is
designed using a data model convenient for conceptual
design, to relieve the problem of the defining a set of attributes and a set of constraints that faithfully represent a
real system and its business rules;
• A subschema is defined using the concepts of the relational data model, according to the appropriate external
schema. The potential database schema is created by the
integration of the designed set of subschemas. Relational
data model enables the automatization of the process of
subschema integration. Consequently, the designers
should concentrate on the semantics concerning the design of the external schemas, rather than on formal
problems and complex techniques of the design of an
integrated database schema.
The relationship between a database schema and a subschema is formalized by the notion of database update
principles and the formal consistency of a subschema and
the database schema. The formal consistency is a necessary
condition for the database update principles. A subschema
is a component of the transaction program specification.
Thus, the process of its design should adhere to the formal
consistency conditions. One of the consequences is that the
set of subschema constraints must imply all those database
schema constraints that might be violated by the allowed
update operations of the subschema.
Checking the formal consistency is relaxed by considering the implicational problem for each constraint type
separately. The common algorithm for the detection of
constraint inconsistencies between the database schema
and a subschema, presented in the paper, operates on the
level of the same constraint type.
A future work should lead towards:
• the sufficient conditions that will imply the database
update principles; and
• some specific algorithms for different constraint types
based on the common algorithm, presented in the paper.
VIII.
REFERENCES
[1] Luković I., Mogin P., Govedarica M., Ristić S., "The
Structure of A Subschema and Its XML Specification", in Proceedings of the XIII International Conference on Information and Intelligent Systems, Varaždin, Croatia, September 2002, pp. 45-56.
[2] Ristić S., A Research of Subschema Consolidation
Problem, PhD Thesis, University of Novi Sad, Faculty of Economics, Subotica, Yugoslavia, 2003.
[3] Mogin P., Luković I., Govedarica M., Database Design Principles, University of Novi Sad, Faculty of
Technical Sciences & MP "Stylos", Novi Sad, Yugoslavia, 2000.
[4] Luković I., Mogin P., "On The Role of Subschema as
A Component of The Implementation Specification
of A Program", in Proceedings of the VI Symposium
on Computer Science and Information Technologies
YUINFO, Kopaonik, Yugoslavia, March 2000, on CD
ROM.
[5] Mogin P., Luković I., "An Approach to Database
Design", International Journal of INDUSTRIAL SYSTEMS, Vol. 1, No. 2, Novi Sad, Yugoslavia, December 1999, pp. 59-68.
[6] Codd E. F., The Relational Model for Database Management Version 2, Addison-Wesley-PublishingCompany, USA, 1990.
[7] Langerak R., "View Updates in Relational Databases
with An Independent Scheme", ACM Transactions on
Database Systems, Vol. 15, No. 1, 1990, pp. 40-66.
[8] Dayal U., Bernstein P., "On the Correct Translation
of Updates on the Relational Views", ACM Transactions on Database Systems, Vol. 8, No. 3, 1988, pp.
339-365.
[9] Bancilhon F., Spyratos N., "Update Semantics of
Relational Views", ACM Transactions on Database
Systems, Vol. 6, No. 4, 1981, pp. 557-575.
[10] Luković I., Mogin P., Ristić S., "A Database Schema
Design Using The Subschemas", in Proceedings of
the XII International Conference Industrial Systems
IS 2002, November 22-23, 2002, Vrnjacka Banja,
Yugoslavia, pp. 340-347.
[11] Ristić S., Luković I., Mogin P., "The Detection of
Database Constraint Inconsistencies", in Proceedings
of the XII International Conference Industrial Systems IS 2002, November 22-23, 2002, Vrnjacka
Banja, Yugoslavia, pp. 348-353.
[12] Ristić S., Mogin P., Luković I., "Specifying Database
Updates Using A Subschema", in Proceedings of the
VII International Conference On Intelligent Engineering Systems INES 2003, March 4-6, 2003, AssiutLuxor, Egypt, pp. 203-212.