OBJECT NORMALIZATION AS THE CONTRIBUTION TO THE

AREA OF FORMAL METHODS OF OBJECT-ORIENTED

DATABASE DESIGN

Jan Vran

Department of Computer Science, Faculty of Electrical Engineering, Czech Technical University in Prague

Technick

a 2, Prague 6, 160 00

Zden

ek Struska, Vojt

ech Merunka

Department of Information Engineering, Faculty of Economics and Management, Czech University of Agriculture in Prague

Kam

yck

a 129, Prague 6 - Suchdol, 165 21

Keywords:

Data normalization, object data model (ODM), relational data model (RDM), ﬁrst object normal form (1ONF),

second object normal form (2ONF), third object normal form (3ONF).

Abstract:

In the article there is described an overview of current status in the area of formal technique of object database

design. It is discussed there, why relational design techniques as normalization, decomposition and synthesis

are not able to be easy used in object databases. The article informs with various proposals of object normal

forms and it brings own authors evaluation and an example of object normalization.

1 INTRODUCTION

Nowadays many various object databases are used

practically. (Authors of this paper have the most of

experience with Gemstone system). The program-

mers and experts have many implicit knowledge and

experience concerning an effective application devel-

opment. Unfortunately the knowledge is expressed

very few in a form of formal rules and procedures,

which would be accepted in the programming com-

munity. Therefore in the practice, we can see wrong

usage of relations and hierarchies among objects,

breakneck tricks in code, etc. The problem of these

applications is not that they do not work. Unfortu-

nately really monstrous constructions work thanks to

modern components and development environments.

The discussion with designer is all the more worse

that he has to rebuild his running system, because he

is not disposed to listen the arguments about difﬁcult

maintenance, extensibility, reliability, risk of data in-

consistency and redundancy.

This is why we decided to discuss the formal tech-

niques of object databases design. Database is the

fundamental of practically all software applications

and object databases are technology, which will grad-

ually attain the importance. Many myths exist in the

community of software producers. For example very

popular is the myth that we need not complete any

normalization, because object databases allow opera-

tions with objects in any form in contrast to the rela-

tional.

2 OBJECT NORMALIZATION

Some various papers arised in the turn of 1980s and

1990s (for example (Wai, Yiu-Kai, Embley, 1992)).

First papers applied to the enlargement of relational

techniques, but we can meet the original papers in last

years.

2.1 Nootenboom’s OONF

First three normal forms for relational and object

databases are universally valid according to Dutch au-

thor Henk Nootenboom (Nootenboom, 2002). As a

substitute for the fourth and ﬁfth relational normal

form (and probably BCNF) he sets up the concept

of only one object normal form, which has following

deﬁnitions:

A collection of objects is in OONF if it is in 3NF

and contains meaningful data elements only.

Universal validity of 1NF, 2NF and 3NF is abso-

lutely right idea that we can agree with, but we leave

without comment the OONF deﬁnition.

471

Vraný J., Struska Z. and Merunka V. (2006).

OBJECT NORMALIZATION AS THE CONTRIBUTION TO THE AREA OF FORMAL METHODS OF OBJECT-ORIENTED DATABASE DESIGN.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 471-474

DOI: 10.5220/0002489304710474

 SciTePress

2.2 Khodorkovsky’s ONF, 4ONF,

5ONF and 6ONF

The paper (Khodorkovsky, 2003) sets up the idea

of object normal form (ONF), which concerns the

“right” relation among data of object and methods

of object. Khodorkovsky’s rule is added to classi-

cal “relational” deﬁnitions 4NF, 5NF (and to the 6NF,

which is author’s enhancement of the 5NF). The au-

thor calls these additions to classical deﬁnitions as

4ONF, 5ONF and 6ONF.

The paper is considered to more qualiﬁed formula-

tion of similar ideas as the example above. It is valid

according to the author that 1NF, 2NF and 3NF are

common for relational and object databases.

2.3 “Chinese” ONF

The paper (Yonghui, Zhou, 2001) set up one object

normal form as substitute for all relational normal

forms. It considers the object data model to be simi-

lar to the tree-like data hierarchy in the way of XML.

We suppose that this approach does not concern with

object databases design, as we understand it.

2.4 “Australian-Swiss” ONF

The authors (Tari, Stokes, Spaccapietra, 1997) set up

one ONF by the help of more types of functional

dependences among objects. Concrete ”path depen-

dency” concerns composition of objects and naviga-

bility among objects, ”local dependency” concerns re-

lations of internal object components and ”global de-

pendency” concerns requirements on application. Ob-

jects structure is in ONF then, if users’ requirements

on applications are retrospectively deducible from the

relations among objects. In agreement with our opin-

ion it concerns very interesting contribution to prob-

lem of testing the accordance of suggested object ori-

ented application model with its requirements. We

think, that this problem is related to the other issues

of databases development, but it not solves the prob-

lem we are concetrated on.

2.5 Three Ambler–Beck’s Object

Normal Forms

Three object Ambler–Beck’s normal forms for object

oriented applications are set up in internet (Ambler,

2004) and in the book (Beck, 2003). These normal

forms are analogical with ﬁrst, second and third rela-

tional normal form. The authors deﬁne these normal

forms 1-ONF, 2-ONF and 3-ONF themselves and talk

about them as a tool for objects classes’ normalization

complementary with technique of design patterns.

3 OUR INTERPRETATION OF

THE PROBLEM

All works mentioned here are very important contri-

bution into discussed area. When we resume, what

probably the community of analysts and designers ex-

pect from the technique of object normalization, we

can deﬁne the following conclusion:

1. It has to be very simple, clear, and understandable

and it should work with minimum of concepts sim-

ilarly as it is with ”classical” normalization. We

suppose that implementation of difﬁcult deﬁnitions

distinctively exceeding the range of classical nor-

mal forms, a lot of types of concepts and relations,

is not the right way.

2. It should be focused only on database design, e.g.

on the structure of objects, which will serve as data

storage and manipulation in database systems. It

does not need to work with objects, which are re-

sponsible for ”operation” of applications. There are

design patterns for them and there is no need to sub-

stitute this technique.

3. It is possible, that in the future the object approach

will become universal approach to information sys-

tem analysis, and relational technology will limit it-

self to be only one of possible implementation vari-

ant. So present conditions can be turned to the op-

posite. It would be smart to have the new theory

analogical with entity-relation modelling concept

and relational normalization. In the best case, the

relational normalization (as a tool of the relational

technology) should be deducible from new theory

as its special kind.

We have to deﬁne ﬁrst, what we understand by

database object. Because it “only” serves for data sav-

ing and manipulation. It is not object, which ensures

some behavioural aspects of the software application.

This is why we propose to not work with data and

with methods separately and deﬁne one concept of

“attribute”. We will not distinct, if the particular at-

tribute is implemented into object by its data or if it is

the result value of some method.

There is a question, if this simpliﬁcation is not

large. For example Ambler-Beck’s approach works

directly with data and methods and uses them in its

deﬁnitions. But we think that we can afford this sim-

pliﬁcation for the data objects.

We think that the modiﬁed form of Ambler-Beck’s

approach fulﬁls best all above described requests.

This version was already used in our lessons and prac-

tically in Czech companies, and we shall work on it

further. We suppose that this method should precede

during modelling all possible next thoughts about us-

ing of inheritance, composition and other relations

among objects.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

472

1-ONF

A class is in ﬁrst object normal form (1-ONF)

when its objects do not contain group of repeti-

tive attributes. Repetitive attributes must be ex-

tracted into objects of the new class. The group

of repetitive attributes is then replaced by the

link at the collection of new objects. An object

schema is in 1-ONF when all of its classes are in

1-ONF.

Figure 1: Example of non-normalized form.

In the ﬁgure 1 there is the example in non-

normalized form and in the ﬁgure 2 there is the same

example in 1-ONF. In contrast to the original ap-

proach, we do not assume, that designers recognize

automatically groups of repetitive attributes and have

them extracted out into independent classes. This rule

is really necessary according to our experience from

school and practice. The problem is not always triv-

ial as in mentioned example. Repetitive attributes can

exist under under various names and they are not al-

ways easy visible for the ﬁrst sight.

Figure 2: 1-ONF.

2-ONF

A class is in second object normal form (2-

ONF) when it is in 1-ONF and when its objects

do not contain attribute or group of attributes,

which are shared with another object. Shared

attributes must be extracted into the new ob-

jects of new class, and in all objects, where they

appeared, must be replaced by the link at the

shared object of new class. An object schema

is in 2-ONF when all of its classes are in 2-ONF.

It concerns the attributes - supplier’s ﬁrst name,

supplier’s surname and his address and client’s ﬁrst

Figure 3: 2-ONF.

name, client’s surname, his address and method of

payment in our example. These attributes were shared

for concrete order and concrete supply. Hence it was

necessary to establish new object class Contract.

3-ONF

A class is in third object normal form (3-ONF)

when it is in 2-ONF and when its objects do not

contain attribute or group of attributes, which

have the independent interpretation in the mod-

elled system. These independent attributes must

be extracted into objects of new class and in ob-

jects, where they appeared must be replaced by

the link at this new object. An object schema is

in 3-ONF when all of its classes are in 3-ONF.

Figure 4: 3-ONF.

It concerns the data about suppliers and client in

the objects of class Contract. These attributes have

independent interpretation without contracts, because

they represent particular persons. And we can declare

the same about the addresses.

Our approach mentioned here brings many ques-

tions and themes to next thought. One of them is a

question, how the inheritance and other used relations

among objects can be included into this approach.

The consideration offers, that right use of inheritance

would be interested next fourth object normal form.

When we focus on the process of object normaliza-

tion, we can see its practical analogy with technique

of applying design patterns and primarily with refac-

toring technique. Our future research will focus on

this direction, where we will try to deﬁne the rules of

object normal forms as a formulation of refactoring

requirements of object database scheme.

Moreover, usage of object database calculus would

be the most suitable for exact description of required

approach. Unfortunately we are still in start of this

area, because one and the only accepted standard is

ODMG-3.0 (Catell, 2000). This model is burdened by

OBJECT NORMALIZATION AS THE CONTRIBUTION TO THE AREA OF FORMAL METHODS OF

OBJECT-ORIENTED DATABASE DESIGN

473

an attempt of convergence with SQL-like object rela-

tional databases and extensively it is oriented on im-

plementation. The authentic formal tool for descrip-

tion of object database scheme is still missing.

4 CONCLUSION

It is a pity, that so perspective and practical used

database technology has not yet comprehensible and

universally accepted theoretical foundation and for-

mal techniques of design. It is unquestionable, that

many research centres are interested in this theme, but

coherent and universally accepted results were not yet

published. Absence of common formal tool and tech-

nique makes the large incompatibility of present ob-

ject database systems, even if they are very good prac-

tically used product themselves. Therefore we sup-

pose that near future brings maybe a few alternative

approaches.

Authors would like to acknowledge the support of

the research project MSM6046070904 on knowledge

management information system design of the Czech

Ministry of Education.

REFERENCES

Ambler, S. (1997) Building Object Applications That Work,

Your Step-By-Step Handbook for Developing Robust

Systems Using Object Technology. Cambridge Uni-

versity Press/SIGS Books, 1997, ISBN 0521-64826-2

Ambler, S. (2004) Object Orientation – Bringing

data professionals and application developers to-

gether. http://www.agiledata.org/essays/ objectOrien-

tation101.html.

Barry D. (1996) The Object Database Handbook:

How to Select, Implement, and Use Object-Oriented

Databases. ISBN 0471147184

Beck K. (2003) Agile Database Techniques – Effective

Strategies for the Agile Software Developer. John Wi-

ley & Sons; ISBN 0471202835

Blaha M., Premerlani M. (1997) Object–Oriented Modeling

and Design for Database Applications. Prentice Hall,

ISBN 0-13-123829-9

Carda A., Merunka V., Pol

ak J. (2003) Um

ı syst

emov

eho

avrhu – objektov

e orientovan

a tvorba informa

ıch

syst

em pomoc

ı pvodn

ı metody BORM. Grada, Praha

2003. ISBN 80-247-0424-2.

Catell R. G. (2000) The Object Database Standard: ODMG

3.0 ISBN 1558606475

Gemstone Systems Gemstone Object Server

– documentation & non-commercial ver-

sion download. http://www.gemstone.com,

http://smalltalk.gemstone.com.

Hru

ska T. (1995) Objektov

e orientovan

e datab

azov

e tech-

nologie. Proceedings of the conference Tvorba soft-

waru 1995, ISBN 80-901751-3-9

Khodorkovsky V. V. (2002) On Normalization of Relations

in Databases. Programming and Computer Software

28 (1), 41-52, 2002, Nauka Interperiodica, ISBN: 5-

02-002404-X.

Kroha P. (1995) Objects and Databases. McGraw Hill,

London 1995, ISBN 0-07-707790-3.

Loomis M., Chaundri A. (1997) Object Databases in Prac-

tice ISBN 013899725X

Merunka V. (2003) Object database system Gemstone Pro-

ceedings of the conference OBJEKTY 2003. Ostrava

2003. ISBN 80-248-0274-0

Molhanec M.: Some comments to the interpretation of the

Object oriented paradigm Proceedings of the con-

ference OBJEKTY 2005. Praha 2005. ISBN 80-248-

0672-X

Nootenboom H. J. (2002) Nut’s – a online col-

umn about software design. http://www.sum-it.nl/

en200239.html.

Tari Z., Stokes J., Spaccapietra S. (1997) Object Nor-

mal Forms and Dependency Constraints for Object-

Oriented Schemata. ACM Transactions on Database

Systems 513-569, Vol 22 Issue 4, December 1997.

Wai Y. M, Yiu-Kai N. Embley D. W. (1992) An Improved

Nested Normal Form for Use in Object–Oriented Soft-

ware Systems. Proceedings of the 2nd International

Computer Science Conference: Data and Knowledge

Engineering: Theory and Applications, pp. 446-452,

Hong Kong, December 1992.

Yonghui W,, Zhou A. (2001) Research on Normalization

Design for Complex Object Schemes. Info-Tech and

Info-Net, vol 5. 101-106, Proceedings of ICII 2001,

Beijing.

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

474