Custom Writing Service http://StudyHub.vip/An-Object-Oriented-Database-Model-Appro 👈

1. v
TABLE OF CONTENTS
ABSTRACT.............................................................................................................................iii
ACKNOWLEDGEMENTS ................................................................................................... iv
LIST OF ILLUSTRATIONS................................................................................................. ix
LIST OF TABLES...................................................................................................................xi
SECTION
I. INTRODUCTION.................................................................................................................1
A. BACKGROUND.................................................................................................................1
1. Evolution of the Manufacturing Resource Planning Information System...........................1
2. An Overview of the Manufacturing Resource Planning Information System................... 3
a. Manufacturing Systems....................................................................................................... 3
b. Financial Systems ............................................................................................................... 6
c. Engineering Systems........................................................................................................... 7
d. Marketing Systems.............................................................................................................. 8
3. The Customer Order Entry System .................................................................................... 8
B. PROBLEM DEFINITION AND OBJECTIVES OF STUDY ......................................... 9
C. CONCEPTS AND AN OVERVIEW OF A DATABASE DESIGN...............................10
1. Definitions of Database, Database Model, and Database Management System.............. 10
2. Descriptions of Object Orientation, Object-Oriented Database, Database Model,
Database Management System, and Programming............. 11
3. Phases of a Database Design ..............................................................................................13
D. AN OVERVIEW AND GENERAL APPROACH OF STUDY..................................... 17
E. ORGANIZATION OF THE SECTIONS......................................................................... 19
II. REVIEW OF LITERATURE ........................................................................................... 21
A. AN OVERVIEW AND COMPARISON OF DATABASE TECHNOLOGIES............ 21
1. Evolution of the Classical Database Technologies........................................................... 21
a. The File Systems................................................................................................................ 21
b. The Hierarchical and Network Database Technologies.................................................... 22

2. vi
c. The Relational Database Technology................................................................................ 26
2. Shortcomings of the Classical Database Technologies..................................................... 32
3. General Features of the Semantic Database Models......................................................... 34
4. Shortcomings of the Semantic Database Models.............................................................. 39
5. Next-Generation Database Requirements......................................................................... 41
6. Proposed Database Technologies...................................................................................... 43
a. The Object-Oriented Database Technology ...................................................................... 43
b. The Extended-Relational Database Technology............................................................... 47
7. Discussions on the Object-Oriented and Extended-Relational Database
Technologies........................................................................ 51
8. Comparisons of the Object-Oriented Database Technology with: ................................... 55
a. Hierarchical and Network Database Technologies ........................................................... 55
b. Relational Database Technology....................................................................................... 58
c. Semantic Database Models................................................................................................ 69
B. CONCLUSION................................................................................................................. 72
III. MODEL DEVELOPMENT AND APPLICATION....................................................... 74
A. CONCEPTS AND DEFINITIONS.................................................................................. 74
1. An Overview of the Core Object-Oriented Database Model Features............................. 74
a. Object and Object Identity................................................................................................. 74
b. Attributes............................................................................................................................ 77
c. Methods.............................................................................................................................. 79
d. Encapsulation and Message Passing ................................................................................. 82
e. Class ................................................................................................................................... 84
f. Class Hierarchy and Inheritance......................................................................................... 87
2. An Overview of the Object-Oriented Entity-Relationship Model (OOERM) and
OOER Language.................................................................. 91
B. THE CUSTOMER ORDER ENTRY SYSTEM IN MANUFACTURING..................101
1. Departments Overview.....................................................................................................101

3. vii
a. Design and Engineering....................................................................................................101
b. Inventory Management.....................................................................................................102
c. Planning.............................................................................................................................102
d. Purchasing and Receiving.................................................................................................103
e. Sales...................................................................................................................................103
f. Shipping.............................................................................................................................105
2. The Customer Order Entry System Modules ...................................................................106
a. Customers..........................................................................................................................106
b. Customer Orders Modules................................................................................................109
c. Inventory Items Modules ..................................................................................................115
d. Line Items Modules ..........................................................................................................119
e. Receipts .............................................................................................................................127
f. Sales Employees................................................................................................................128
C. AN OBJECT-ORIENTED LOGICAL CUSTOMER ORDER ENTRY
DATABASE DESIGN....................................................................130
1. An Object-Oriented Analysis and Conceptual Schema Design of the Customer
Order Entry Database..........................................................130
a. Objects and Object Identifiers...........................................................................................131
b. Classes and Class Hierarchies ..........................................................................................135
c. Attributes...........................................................................................................................143
d. Methods and their Message Passing.................................................................................158
2. An Object-Oriented Implementation Design of the Customer Order Entry
Database..............................................................................175
IV. MODEL EVALUATION...............................................................................................178
V. CONCLUSION...............................................................................................................200
APPENDIX - LOGICAL SCHEMES..................................................................................211
BIBLIOGRAPHY.................................................................................................................231
VITA .....................................................................................................................................239

4. viii
LIST OF ILLUSTRATIONS
Figures
1.An Overview of the Manufacturing Resource Planning Information System.................. 4
2.Phases of a Database Design ............................................................................................ 15
3.An Illustration of the Hierarchical Database Model ........................................................ 24
4.An Illustration of the Network Database Model.............................................................. 25
5.An Illustration of the Relational Database Model............................................................ 27
6.Illustrations of some Semantic Database Models ............................................................ 37
7.An Illustration of the Generalized Semantic Database Model......................................... 40
8.An Illustration of an Object-Oriented Database Model................................................... 46
9.An Illustration of the Object-Oriented Entity-Relationship Diagram (OOERD).............99
10.The Classes and Class Hierarchies of the Customer Order Entry Database...................144
11.Customers Class...............................................................................................................145
12.Customer Orders Hierarchy.............................................................................................147
13.Inventory Items Hierarchy...............................................................................................148
14.Line Items Hierarchy........................................................................................................149
15.Receipts Class..................................................................................................................150
16.Sales Employees Class.....................................................................................................151
17.The Structural Representation of the Customer Order Entry Database..........................157
18.Order Entry and Acceptance............................................................................................162
19.Order Filling.....................................................................................................................163
20.Filling Backorder .............................................................................................................165
21.Shipment Requesting and Customer Billing...................................................................166
22.Delivering Line Item........................................................................................................167
23.Customer Payment...........................................................................................................168

5. ix
LIST OF TABLES
Tables
I.Customers Class ...............................................................................................................211
II.Customer Orders Hierarchy..............................................................................................213
III.Inventory Items Hierarchy................................................................................................217
IV.Line Items Hierarchy .......................................................................................................221
V.Receipts Class ..................................................................................................................227
VI.Sales Employees Class ....................................................................................................229

6. iv
ABSTRACT
Conventionally, like the other systems of the manufacturing resource planning
information system, customer order entry databases have also been developed under the
traditional database technologies. However, for any kind of application, the object-oriented
database technology has been proposed as a powerful alternative database technology over
the traditional (hierarchical, network, and relational) technologies and semantic database
models regarding the database design and application capabilities of its features.
Therefore, in order to design structural and behavioral characteristics of the entire
customer order entry database effectively, a superior database model, such as an object-
oriented database model, should be used as a base.
The purpose of this study is to explain and demonstrate the entire logical customer
order entry database design (especially, from the manufacturing perspective) based on the
core object-oriented database model features (e.g., object, object identity, attributes,
methods, encapsulation and message passing, class, class hierarchy and inheritance, and
some semantic relationships among objects). In doing so, the Object-Oriented Entity-
Relationship Model (OOERM) is used as an object-oriented analysis and conceptual design
tool. Subsequently, the syntax of the OOER Language (OOERL) is utilized informally as a
data definition (DDL) and manipulation language (DML). Finally, the advantages of the
core object-oriented database model features on the logical customer order entry database
design are explained.

7. v
ACKNOWLEDGEMENTS
I thank my dear wife, Damla, whose love, encouragement, and patience were a
constant source of strength throughout the duration of this dissertation, and my son, Aral,
whose lovely smile was the greatest motivation for realizing this work. Special thanks also
go to Dr. Omurtag, my advisor, whose helpful suggestions and also whose patience and
support have helped to make this dissertation a reality. I also thank my committee members,
Dr. Daily, Dr. Benjamin, Dr. Greenway, and Dr. Prater for their assistance. Their efforts are
appreciated. Additionally, I am grateful for the research assistance I received from the UMR
library personnel.

8. I. INTRODUCTION
A. BACKGROUND
The "manufacturing resource planning (MRP II) information system" is the
management technique that optimizes a manufacturer's engineering, manufacturing,
marketing, and financial systems. The entire business and financial environment is managed
for the utmost in efficiency, output, consumer satisfaction, and company growth and profit.
Implementation of the MRP II information system results in the automation of the
information flow in a business organization from the pre-sale system (including bid
proposal) or receipt of the order, through the steps in the administrative and technical
processes, to the shipment of the finished product.
Under this subheading, the evolution of the MRP II information system, its systems,
and briefly, the customer order entry system (which is the focus of this dissertation) is
described. The reason for these discussions is to highlight the necessary systems for the sake
of understanding their interrelationships in the whole system. Most of the material described
under this subheading is reorganized and summarized material from the referenced papers
[1-14].
1. Evolution of the Manufacturing Resource Planning Information System In the
1960s, with the proliferation of computers and their growing popularity, manufacturers
looked for a way to use them to facilitate their ordering of materials and parts for their
manufacturing activities. The outgrowth of this demand was the old "material requirements
planning" (MRP) concept. MRP was a simple computer software for planning material
orders with the purpose of reducing inventory, responding more effectively to market
demand, and ultimately increasing sales. The original MRP programs
matched material requirements with inventory levels and existing replenishment purchase
orders and work orders over a time horizon. Despite this new method, which improved
inventory control and planning for materials, many manufacturers realized there were pieces
of the manufacturing puzzle that were missing.

9. 3
The next phase of MRP was the addition of techniques to plan for the capacity
requirements planning as well as scheduling. Managers realized that planning for materials
was critical, but if the plant did not have the capacity to produce the final goods inventory,
the materials planning was not effective. The inclusion of the capacity requirements
planning and scheduling into the basic MRP functions formed the basis for a new concept
called "closed-loop manufacturing." It compares the work load of a manufacturing site to its
actual capacity and is concerned with labor and material planning at the scheduling level. A
closed-loop environment provides feedback which shows imbalances in work center
loading and can provide suggestions to correct the problems. This new phase in
manufacturing automation contributed to a manager's capability to manage effectively an
entire manufacturing environment. However, it was soon noted that there was no real link
between the capabilities of the new closed-loop manufacturing features and the strategic and
business plans of the company.
With that realization, "manufacturing resource planning" (MRP II) evolved. MRP II
is an extension of closed-loop manufacturing because it provides the important financial
and marketing dimensions to the manufacturing environment. With MRP II manufacturing
companies can now effectively plan all of the resources of their organization. In addition, an
MRP II system also provides some sort of what-if analysis and simulation capability to
evaluate alternative plans, to anticipate future problems, and to react more quickly to
changing economic situations. Thus, MRP II is the newest link in the manufacturing
automation chain that includes the material requirements capacities of the old MRP
concept; the capacity requirements planning, shop floor control, and master production
scheduling of the closed-loop MRP; and the added dimension of financial and marketing
planning.
2. An Overview of the Manufacturing Resource Planning Information System
Functionally, an MRP II information system comprises an integrated series of systems to
satisfy the manufacturing, financial, engineering, and marketing requirements of a

10. 4
corporation (see Figure 1). Each MRP II information system must have the basics in order
to satisfy a company's manufacturing and business requirements.
a. Manufacturing Systems The manufacturing systems mainly include master
production scheduling (MPS), material requirements planning (MRP), capacity
requirements planning (CRP), resource requirements planning (RRP), shop floor control
(SFC), inventory management and control (IC), purchasing, and cost accounting (CA).
Figure 1. An Overview of the Manufacturing Resource Planning Information System

11. 5
Master Production Scheduling (MPS). This system drives several of the other
systems, such as MRP & CRP, in a manufacturing setting with the purpose of controlling
plant activities from raw material ordering to the final assembly of the product. MPS
translates the company's business plan and revenue projections into actual production
requirements and indicates what is to be manufactured and in what quantities. In order to
provide accurate manufacturing figures it must validate the plant capacity and provide
accurate resource planning.
Material Requirements Planning (MRP). The purpose of this system is to define the
materials needed at each work center location in order to meet the schedule developed in
MPS. MRP uses a time-phased projection of available inventory, which gives it the
capability to recommend when manufacturing orders or purchase orders need to be
rescheduled if due dates and required dates are not valid. In order to create the material
requirements plan, MRP also uses other inputs, such as bill of materials, shrinkage factors,
lot sizes, and lead times.
Capacity Requirements Planning (CRP). This system determines how much labor
and machine capacity is required to meet production levels and makes plans to provide
these resources. CRP receives input from the MRP in the form of production schedules and
from the SFC system in the form of shop orders. These inputs are then translated by CRP
into hours of work by individual work centers, which provide capacity needs. The data on
the individual work center capacity and efficiency factors are then passed to the CRP system
for the capacity requirements calculations.
Resource Requirements Planning (RRP). The purpose is to evaluate a production
plan before having to actually implement it. By analyzing the manufacturing company's
capability to execute the production plan, managers can examine the impact that critical
resources have on the anticipated schedule. This gives them the opportunity to determine
how realistic the MPS is. RRP is a more generalized form of CRP because its main purpose
is to evaluate the impact of a production schedule rather than determining the actual load on
individual resources as CRP does.

12. 6
Shop Floor Control (SFC). This system is a control tool designed to monitor status
information on manufacturing orders and work centers. SFC determines when operations
are to be started and completed, sets operation priorities for each work center, and monitors
the progress of the orders and the performance of the work centers. As priorities are
changed in the MRP system, SFC reschedules the work in response to the changes. It also
interfaces to the CRP, and with this process, ineffective work centers can be identified to
provide more effective work center utilization.
Inventory Management and Control (IC). The IC system integrates with nearly all
systems of the MRP II system and must manage the balance between required inventory and
available inventory. The IC system must control the issue and transfer of material, adjust
inventory levels, and ship products.
Purchasing. In an effort to reduce costs and to keep inventory at a minimum, the
purchasing system accounts for delivery lead times, projected inventory needs, and cost
trends. Purchasing receives input from the IC system in the form of current and anticipated
inventory levels. MRP also provides input about planned inventory use and generates
planned requisitions for purchased parts.
Cost Accounting (CA). In its effort to maintain profitability and to meet the goals of
the business plan, any manufacturing environment must be able to control and monitor its
costs and to know the cost of the final products. The major costing elements include
material and labor, variable and fixed overhead, machine setup cost, and subcontractor
costs.
b. Financial Systems Principally the financial systems consist of accounts payable
(AP), accounts receivable (AR), general ledger (GL), fixed assets (FA), and payroll systems.
Accounts Payable (AP). It is important to balance payment cycles in order to assure
continued, on-time delivery. Integrating AP with the purchasing system can provide an
invoice-matching process to manage accurately cash flow and to guarantee accurate
payment for received material. Many AP systems provide history reports on vendors,
payments, and discounts taken, which are essential for accurate cost control.

13. 7
Accounts Receivable (AR). Credit lines should be carefully controlled; the inclusion
of a credit history function is necessary in order to estimate receipts and to manage
accurately cash flow. AR integration with the order processing provides immediate credit
checking, which ensures that before an order is accepted, the customer's line of credit is
high enough for the order and that the credit is satisfactory.
General Ledger (GL). Most manufacturing control systems integrate the AP and AR
systems with GL; many systems also integrate the payroll function with GL. Most GL
systems should provide a complete audit trail of all general ledger transactions.
Fixed Assets (FA). It is essential in a manufacturing environment to manage a
company's depreciable, non-depreciable, and leased assets from acquisitions to transfers and
finally to retirement. The FA system should accommodate depreciation schedules and
techniques to enable the company to manage effectively its capital equipment. The FA
system should be able to accommodate changes in the tax code.
Payroll. This system is usually integrated with the GL system and with the personnel
or CA system. The interface with the CA system allows the payroll system to generate and
monitor time cards and issue paychecks based on hours worked, including overtime. It
might also interface with the order processing system, which then lets the manufacturer
monitor and pay sales commissions.
c. Engineering Systems
Bill of Materials (BOM). This is an engineering database which lists all of the raw
materials, subassemblies, and parts that make up the manufactured product by indicating the
quantity of items that comprise the finished goods. BOM also controls the engineering
changes through affectivity dates and historical reporting. The interface to the IC system
indicates the material requirements for manufacturing orders; the interface with MRP
supports the actual material requirements planning; and the interface with CA provides the
data for roll-up costs.
d. Marketing Systems The marketing systems mainly include order entry (OE), sales
management (SM), and distribution planning (DP).

14. 8
Order Entry (OE). This system is explained in Section I.A.3, The Customer Order
Entry System.
Sales Management (SM). Since many manufacturers deal with customers through
dealers, distributors, or manufacturers' representatives, the SM should accommodate each of
these sales techniques. When the SM system is integrated with the OE system, sales quotas
and performances data can be derived from the movement of data through the system. This
procedure aids in sales analysis by providing sales by product type and salesperson.
Distribution Planning (DP). This system interfaces with MPS to establish safety
stocks and to calculate replenishment order quantities. The system is designed to monitor
inventory levels and distribution resources, such as warehouse space, with the purpose of
reducing inventory levels while maintaining customer service levels.
3. The Customer Order Entry System This system is designed to facilitate both
production scheduling from an internal manufacturing perspective and order tracking from a
marketing, sales-oriented perspective. From a manufacturing perspective, orders are entered
for make-to-stock producers in the OE system and transferred automatically to the MPS
system to schedule the product. Some systems provide an on-line mechanism which allows
users to review the production schedule and promises customers actual ship dates based on
the product completion date. OE also tracks the finished goods inventory and checks its
quantity when customer orders are received, commits the finished goods inventory, and
places goods on inventory hold. These procedures not only facilitate the internal production
functions, but also provide better customer service. Most OE systems also support customer
credit checking, available inventory, generation of quantity price breaks, and audit tracking.
The data from the OE system function aids sales analysis by indicating trends in products,
customer purchases, and sales performance.
B. PROBLEM DEFINITION AND OBJECTIVES OF STUDY
Conventionally, like the other systems of the manufacturing resource planning
information system and other applications, customer order entry databases have also been
developed under the traditional database technologies, which designs them ineffectively. In

15. 9
addition, the only available material about the customer order entry database based on the
object-oriented database technology are papers and books, in which some parts of the entire
customer order entry system are used as an example for the purpose of the authors' relevant
discussions.
On the other hand, for any kind of application, the object-oriented database
technology has been proposed as a powerful alternative database technology over the
traditional (hierarchical, network, and relational) technologies and semantic database
models, because of the database modeling and application capabilities of its features.
For the purpose of this dissertation, in order to capture the descriptions of the
objects and their behaviors and to design effectively the structural and behavioral features of
the entire customer order entry database (mainly, from the manufacturing perspective) a
superior database model should be used as a base as in the case of other databases. Thus, as
for the other databases, it is crucial to get the benefits of an effective database technology,
such as the object-oriented database technology, for designing the entire customer order
entry database properties.
The purpose of this dissertation is to explain and demonstrate the entire logical
customer order entry database design (especially, from the manufacturing perspective)
based on the core object-oriented database model features (e.g., object, object identity,
attributes, methods, encapsulation and message passing, class, class hierarchy and
inheritance, and some semantic relationships among objects). In doing so, the Object-
Oriented Entity-Relationship Model (OOERM) is used as an object-oriented analysis and
conceptual design tool. Subsequently, for the implementation phase of the logical customer
order entry database design, the syntax of the OOER Language (OOERL) is utilized
informally as a data definition (DDL) and manipulation language (DML).
Finally, the advantages of the core object-oriented database model features on the
logical customer order entry database design are explained.

16. 10
C. CONCEPTS AND AN OVERVIEW OF A DATABASE DESIGN
1. Definitions of Database, Database Model, and Database Management System
[15]. A "database" is a collection of interrelated data stored together on a physical media
without inconsistency or redundancy to serve one or more applications in an optimal
fashion; a controlled approach is used in adding new data and in modifying and retrieving
existing data within the database. The customer order entry database is an example of a
database.
A "database model" is a schema to model the structure of the data in the database.
Classical and object-oriented database models are examples of a database model.
A "database management system" (DBMS) is a general-purpose tool that adapts the
logical structuring, physical storage, and control of data and provides a number of user
interfaces to the functioning of the enterprise. IMS, CODASYL, dBASE IV, ORACLE,
ORION, and OBJECTSTORE are examples of a database management system.
2. Descriptions of Object Orientation, Object-Oriented Database, Database Model,
Database Management System, and Programming [16-17]. "Object orientation" can be
described as the software modeling and development (engineering) discipline that make it
easy to construct complex systems from individual components. The intuitive appeal of
object orientation is that it provides better concepts and tools with which to model and
represent the real world as closely as possible; interacts easily with a computational
environment using familiar metaphors; constructs reusable software components and easily
extensible libraries of software modules; easily modifies and extends implementations of
components without having to re-code everything from scratch, etc. Object orientation starts
with an object-oriented model and data languages that capture it and extends them in
various ways to allow additional capabilities. The fundamental aspects of the "object-
oriented paradigm" are abstract data typing, inheritance, encapsulation, polymorphism,
object identity, etc. Each of these concepts contributes to the software engineering and
modeling properties of object-oriented systems.

17. 11
An "object-oriented database" is a collection of objects on a physical media, whose
behavior, state, and relationships are defined in accordance with an object-oriented database
model. The object-oriented customer order entry database is an example of an object-
oriented database.
An "object-oriented database model" consists of object-oriented concepts for
modeling data. A survey of semantic database models, object-oriented programming
languages and knowledge representation languages can bring out a set of commonly
accepted and fundamentally important data modeling concepts. This set of modeling
concepts forms the "core object-oriented database model." These concepts are object and
object identity, attributes and methods, encapsulation and message passing, class, class
hierarchy, and extensibility feature (inheritance and behavioral extension). The core
database model includes some important "semantic relationships" among objects, such as
instance-of, aggregation, and generalization. However, the core database model does not
capture some of the "semantic integrity constraints" and "semantic relationships" that are
important to many types of applications. Two of the most important modeling concepts for
data-intensive applications are composite objects and versions.
Therefore, an object-oriented database model is defined as a core model augmented
with semantic integrity constraints and a number of semantic relationships.
An "object-oriented database management system" (OODBMS) is a system that
includes object-oriented concepts together with three basic interfaces, which are data
definition (DDL), data manipulation (DML), and data control languages (DCL). An
OODBMS supports a unified object-oriented programming and data languages
environment, as they are based on the object-oriented concepts. The main purpose of an
OODBMS is to organize logically and physically the real-world objects, the constraints on
them, and the relationships among objects. This in turn means that programmers need not
explicitly program and manage these relationships. ONTOS, GEMSTONE, ORION,
OBJECTSTORE, and O2 are examples of an OODBMS.

18. 12
"Object-oriented programming" is a method of implementation in which programs
are organized as cooperative collections of objects, each of which represents an instance of
some class and whose classes are all members of a hierarchy of classes united via
inheritance relationships. In such programs, classes are generally viewed as static, whereas
objects typically have a much more dynamic nature, which is encouraged by the existence
of dynamic binding and polymorphism. Object-oriented programming is based on "object-
oriented concepts," such as abstract data types, methods, polymorphism, dynamic binding,
encapsulation, and reusability. Further, an "object-oriented programming language" may be
extended into a unified programming and data language, which has less of an impedance
mismatch problem. SMALLTALK, C++, Objective C, EIFFEL, and the Common LISP
Object System (CLOS) are examples of object-oriented programming languages.
3. Phases of a Database Design [18-24]. "Database design" involves designing the
structure of a database in a given environment of users and applications in which all the
users' data requirements and all the applications' process requirements are best satisfied.
The DBMSs that store and manipulate a database must have a definition of the
database in the form of a schema. This is termed the "intension" of the database. The actual
values of data in a database are called "instances" of data or "extension" of the database.
The database design aims at designing the intension schema of the database, which includes
logical specifications such as groupings of attributes and relationships among these
groupings ("logical schema"), as well as physical specifications such as the type of access to
records, indexes, ordering, and physical placement ("physical schema"). On the basis of this
distinction, the corresponding database design activities are termed logical schema design
and physical schema design.
"Logical schema design" involves the problem of designing the conceptual schema
and mapping such a schema into the "data definition" (DDL) and "data manipulation"
(DML) languages of a specific DBMS and/or programming language. DDL allows the
specification of the database schema. The "schema" of a database is the specification of a
set of relations: Groupings of attributes and relationships among these groupings, functions

19. 13
specifications, data type of each attribute and their relationships, integrity constraints on the
data types, and semantic extensions. DML includes facilities to express "queries" and
"updates" (e.g., replace, insert, delete, etc.) against the database.
"Physical schema design" involves the problem of mapping the logical schema into
the "data control language" (DCL) and various facilities of a specific DBMS and/or
programming language. DCL includes facilities for protecting the integrity of the database
and for managing the resources of the system. The "integrity feature" of a DCL includes
transactions, a limited form of semantic integrity constraints for most systems, and
authorization. The "resource management feature" of a DCL is the specification of the
creation and deletion of database schema elements and access methods to the database (e.g.,
B+ tree secondary indexes, physical clustering of records, etc.). Beyond the features
expressed above, DBMSs provide various facilities, including concurrency control,
recovery, query optimization, performance monitoring, etc.
Figure 2 shows the phases of a database design and the intermediate schema
representations. The "phases of a database design" are:
Requirements Specification and Analysis. This phase analyses the information
requirements of various areas within an organization resulting in a prior specification of the
information needs of various user groups. The analyst seeks to determine the entities,
attributes, and relationships; obtains descriptions, functions, data characteristics, and editing
rules about the entities, attributes, and all known relationships; and obtains facts on the
security, integrity requirements, and semantic extensions of the data.
Conceptual Design. The modeling and representation of the users' and applications'
views of information and possibly a specification of the processing or use of the information
is presented. The final result of this activity is a "conceptual schema" that represents a
global, high-level description of the requirements. The conceptual schema should reflect the
inherent structure of the information being utilized. In this phase, the entities, attributes,
etc., identified in the previous phase are integrated to reflect their interrelationships.

20. 14
Figure 2. Phases of a Database Design

21. 15
Implementation Design. This phase involves transforming a conceptual schema into
the logical schema of a DBMS and/or programming language. The second and third phases
are taken together and are called "logical database design."
Physical Schema Design and Optimization. This phase involves mapping the logical
schema of a database into an appropriate stored representation in a DBMS and/or
programming language, including new physical parameters to optimize the database
performance against a set of transactions.
Typically, "application design" activity proceeds in parallel with database design.
Hence, Figure 2 also shows specifications related to applications as the output of the last
two phases.
D. AN OVERVIEW AND GENERAL APPROACH OF STUDY [16, 17, 25-40]
The starting point and purpose of this dissertation is to demonstrate and explain the
utilization of the standard, fundamental, and powerful features of object orientation on the
entire customer order entry database and to explain their effects on the mentioned database.
Thus, the core model features, (which are object and object identity, attributes and methods,
encapsulation and message passing, class, class hierarchy and inheritance, and some
important semantic relationships among objects, such as instance-of, aggregation, and
generalization) are the features on which this dissertation is based. Selection of the above
features mainly has been based on the following three reasons: Primarily, no standard
object-oriented database model on which to base this dissertation exists, as this technology
is currently in the growth stage. Secondly, as has already been mentioned, at the current
stage, the survey of semantic database models, object-oriented programming languages, and
knowledge representation languages has brought out only the core model concepts [16, 17,
26, 28, 29, 39, 40]. Finally, these are the only fundamental features that are needed in the
logical design of a database.
Roughly, the "top-down design" of an object-oriented database consists of the same
phases that were described and shown in the above subsection.

22. 16
Requirements Specification. In this phase, features of the entire customer order entry
database (from the manufacturing perspective), regarding the ones that were mentioned
above, are determined and given as an input to the object-oriented analysis and conceptual
design phase of this dissertation.
Object-Oriented Analysis and Conceptual Schema Design. In this phase of the
dissertation, the entities, attributes, etc., identified in the previous phase, are integrated to
reflect their interrelationships by the Object-Oriented Entity-Relationship Model (based on
the framework of the core model features).
There are several methods for analyzing and designing object-oriented systems
(such as Wirfs-Brock, 1990; Booch, 1991; Coad and Yourdon, 1991; Object-Oriented
Entity-Relationship Model, 1991; and others) [16, 25, 31-35, 38].
"Object-oriented analysis and conceptual schema design," described simply,
includes the process of identifying and modeling the essential object classes and the logical
relationships and interactions among them.
No mater which object-oriented analysis and design method is employed, most
experts agree that the important factor in the products of analysis and design is the
capability to provide a complete enough model, to realize the two aspects of the analysis
and design of an object-oriented database, which has static and dynamic aspects.
Additionally, at the moment there is no standard, formalized, and ideal approach to carrying
out analysis and design [16, 25, 28, 31, 34, 35, 38].
Accordingly, as no standard and ideal method exists and as the static and dynamic
aspects of analysis and design are covered, the "Object-Oriented Entity-Relationship
Model" (OOERM) has been selected for the purpose of this phase.
The "Entity-Relationship" (ER) (especially, the "Extended Entity-Relationship"
[EER]) diagrams are useful for modeling the "structural" features of object-oriented
database; however they do not express the "operational" (dynamic) aspects of such a
database. That is, the EER diagram does not include symbolism for the methods and
messages that are the essential features of the object-oriented database models which bring

23. 17
that model to life. Gorma has proposed an extension to the EER model, called the OOERM
for this purpose, 1991 [35, 36]. The essential and powerful feature of the OOERM is that it
adds formalism for expressing methods and message passing at the conceptual level.
Generalization hierarchies and other core object-oriented relationship constructs are easily
modeled with this approach.
Object-Oriented Logical Schema Design. For the implementation phase of the
logical schema design of this dissertation, the syntax of the "OOER Language" (OOERL) is
utilized informally as a DDL and DML. The reason for selecting OOERL is simply to
preserve the unity with OOERM and its powerful language capability. Additionally, at the
moment no standard and ideal object-oriented database language exists [17, 26, 30, 39].
OOERL is based on Semantic Database Model (SDM), EIFFEL, and Standard Query
Language (SQL) for describing OOERM schema and manipulating its objects [35].
In this way, as it has already been mentioned, the second and third phases are taken
together and are called logical database design, which is realized on the entire customer
order entry system (from the manufacturing perspective).
E. ORGANIZATION OF THE SECTIONS
An overview of the traditional (hierarchical, network and relational) technologies
and semantic database models and their shortcomings are described in the "review of
literature" section. Also, two popular proposed database technologies (for the requirements
of the next-generation databases), the extended-relational and object-oriented, are briefly
introduced and their general characteristics are discussed. Additionally, comparisons of the
object-oriented technology with the classical technologies and semantic database models are
reviewed. Finally, the result of the literature review, especially, for the customer order entry
system is stated.
In the "model development and application" section, the core object-oriented
database model features and the Object-Oriented Entity-Relationship Model (OOERM)
with its OOER Language (OOERL) are first explained, then the entire customer order entry
system is described (from the manufacturing perspective). Subsequently, implementing the

24. 18
core object-oriented database model features by the OOERM for the conceptual design of
the entire customer order entry database is explained and demonstrated. Furthermore, for
the implementation phase of the logical customer order entry database design, utilization of
the informal syntax of the OOERL as a DDL and DML is presented and explained.
Finally, the advantages of the core object-oriented database model features on the
logical customer order entry database design are explained in the "model evaluation"
section.
In the "conclusion" section, facts drawn from the above sections are stated.

25. 19
II. REVIEW OF LITERATURE
A. AN OVERVIEW AND COMPARISON OF DATABASE TECHNOLOGIES
1. Evolution of the Classical Database Technologies During the past three decades,
the database technology for information systems has undergone four generations of
evolution, and the fifth generation database technology is currently under development. The
transition from one generation to the next has always been necessitated by the ever-
increasing complexity of database applications and the cost of implementing, maintaining,
and extending these applications. Additionally, off-loading some tedious and repetitive
bookkeeping functions from the applications into the database management system [41-45].
By "classical database technologies" we mean the three most common and popular
ones used in contemporary management systems: The hierarchical, network, and relational
database technologies.
a. The File Systems [15, 20, 46]. The first generation were "file systems," such as
access methods ISAM and VSAM. The file systems were simple structures used for data
storage. A "file" was organized into a collection of related data called a record. Each
"record" was composed of a fixed number of "fields" (e.g., name, part number, etc.) that
make up a record. Records could be accessed sequentially or randomly by indices created on
one of the fields.
File systems facilitated the task of interfacing programs with centralized persistent
physical storage. Applications were run as batch programs. File systems stored the data
under supervision of the enterprise's data processing professionals and provided uniform
access to the data. These systems eliminated the difficulty of multiple and inconsistent
copies of the same data. However, they were somewhat limited in their ability to store
complex relationships and maintain data integrity, but they had quick recovery. The
characteristics of the first generation system required the user to view and manipulate the
data structures in the configuration in which they were physically stored. Thus the user was
forced to deal with the aspects of physical data organization, which, although important for
machine efficiency, are irrelevant to the user's understanding of the data. Any alteration of

26. 20
that organization in order to improve efficiency necessarily involved considerable
reprogramming effort.
b. The Hierarchical and Network Database Technologies [15, 19-21, 46-48]. The
second generation was the "hierarchical database" technology, such as IMS. The third
generation was the "network database" technology, such as CODASYL. These technologies
provided a significant increase in the availability, security, integrity, and consistency of the
data they stored. They incorporated the concept of a "record" as a collection of named
"fields" to represent each individual object in the application environment. An important
landmark in the development of DBMSs was the attempt to identify a system based on the
network/hierarchical database models.
Both of these technologies realize the sharing of an integrated database among many
users within an application environment, while preventing multiple users from interfering
with each other. This "concurrency control" technology shows up as transaction
management, locking, access control, backup and recovery, and so forth. These DBMSs not
only make database contents shareable, they also make the descriptions of those databases
shareable. This is the essence of "schema management," which takes the responsibility for
characterizing database structures out of the individual programmer's hands. Thus schemes
are leveraged across programs, and data can be managed as a resource that supports
multiple applications. In these models we can manipulate only one record at a time by the
programming language via an access path that is determined in the DBMS, i.e., in a
procedural manner. These DBMSs feature both sequential data access and access to data by
key.
The "hierarchical model" (see Figure 3) allows a "tree-like set" (parent-child
relationships) of one-to-many relationships in which each segment occurs at a single
specified level of the hierarchy (data abstraction). A segment is either a "root segment,"
without a parent, or a child segment. "Child segments" that are not at the leaves of the
hierarchy are also "parent segments." A parent segment can have many child segments, but
each child can have only one parent. Each "node" shown in Figure 3 is called a "segment"

27. 21
and segments are linked by "pointers." These pointers facilitate the capabilities of the
"referential integrity constraints," in the sense that a child segment cannot exist without the
existence of a parent segment. The referential constraint is that the value in the foreign key
must be the same as the primary key in the referenced table. The hierarchical model
produces "duplicated segments" such as some of the line items.
Figure 3. An Illustration of the Hierarchical Database Model
Although hierarchical products support a variety of access modes, overall data
manipulation is "navigational." This means that the accessing of records of a child node is
achieved by hierarchically traversing the parents of the nodes. For example, the typical
processing of customer orders with a hierarchical DBMS involves finding the customer,
locating the first order associated with that customer, and then processing line items
associated with that order until no more remains. The user then leaves one level of the
hierarchy, moves to the next order down the line, and starts to process line items until no
more remains to be processed. Users do not need to track position because the DBMS does

28. 22
that; they simply skip to the next order, line item, or customer. Extensive additional
processing is required for some queries as there is no direct link between some segments.
Another limitation is that deleting a parent segment instance automatically deletes all of the
corresponding child segment instances.
The "network model" (see Figure 4) provides the set mechanism to establish one-to-
many associations between any "owner record" and a number of "member records," thus
allowing a "network of relationships." Owner records can have many members, and a
member can have more than one owner. Each "node" in Figure 4 is called a "record" and is
linked with every other node by "pointers" that realize some capabilities of the "referential
integrity." The network model does not produce "duplicated records" or "fields." Record
types and set types are specified by a DDL that defines the schemes for a database. The
DML makes use of "navigation operations." But with the network model the navigation is
richer since we can navigate to a member through one set, then navigate to an owner from
another set.
Figure 4. An Illustration of the Network Database Model

29. 23
These models fail to capture much of the semantics associated with the data. As a
result, they require extensive additional constraints to maintain the semantic integrity of the
database. The network and hierarchical database implementations do not have "physical
data independence." This means that the user's view of the hierarchical and network
database implementations, i.e., the exact form of the statements available to the programmer
to conduct this navigation reflects the way the data is organized, stored, and accessed from
the underlying physical storage media. A consequence is that the database schemes are often
difficult to design. Relationships between the records and/or structure of the database in
these models are not easily changed as well. Besides the specification hassle, this approach
severely limits the extensibility, maintainability, and reusability of the database applications
that are developed from these models. As a result, users are required to write complex
programs in procedural fashion to carry out retrieval and update functions.
c. The Relational Database Technology [15, 19-21, 46-57]. Primarily the lack of
data independence and the tedious navigational access to the database gave rise to the fourth
generation database technology, namely, the "relational database technology" (see Figure 5),
such as ORACLE, SQL/DS, DB2, and INGRES.
The relational database technology is composed of three aspects: Structure, integrity,
and manipulation. The "structure" of the relational model is a collection of "tables" called
"relations." Each "box" shown in Figure 5 is called a table. Each relation (table) corresponds
to an "entity type" or "relationship type" also called a "file." For example, the Customer and
Inventory Product are entity tables and the Line Item is a relationship table. In another
example, the relationship between the Existing Accepted Order and Inventory Product
tables are represented by the Line Item table. The rows of a table are called "tuples" or
"records" and represent instances of the entity or relationship type, in which the sequencing
of the instances and the sequencing of the fields within the type are trivial. Any kind of data
in a relational database is explicitly represented as values in tables. The columns of the table
are the "attributes" called "fields" of the entity type or relationship type. The set of all
possible values that can appear in a given column is called the "domain" of the attribute.

30. 24
Figure 5. An Illustration of the Relational Database Model
In general, a table is associated with another table by attribute values in their
respective columns which are drawn from a common domain. For example, in Figure 5 the
Inventory Product and Line Item tables are associated via the Product Number domain that
is common to both tables. In general, a relationship or entity relation contains the "primary
key" attributes to uniquely identify the entities involved. For example, the attribute Product
Number has unique and defined values for each instance of the Inventory Product table. The
Line Item Number together with the Order and Product Number attributes uniquely identify
instances of the Line Item relationship table. The relational model produces "duplicated
columns" because of the "foreign key," such as the Customer Number attribute in the
Existing Accepted Order table (see Figure 5).
The relational database model is value-based, as opposed to earlier, identity-based
models like IMS and CODASYL. This distinction is based on the mechanisms that a
database model provides for relating entities to one another. A "value-based" model
expresses the relationship between two entities by embedding the same value in two or
more related objects. An "identity-based" model can relate two or more entities
independently of embedded values or the context in which they are embedded.

31. 25
The relational database model accommodates only types and, unlike the other two
classical database models, it does not explicitly specify relationships between relations in
the schema. It is based on the concept of mathematical relations. Logically, relations
describe entities and interrelationships among them. Interrelationships that aren't depicted as
tuples can be dynamically established at access time using the relational data manipulation
facilities (e.g., joins). Thus, unlike the other two models, the user is not restricted to the
predefined relationships.
Basically, relational database design is a process of determining first what tables are
needed to represent application entities and their relationships, and then optimizing those
table structures for efficient performance. Typically, a technique called normalization is
applied to design the tables. "Normalization" is a data-analysis process used to find the
simplest possible data structure for a given collection of information by eliminating the
replication of data across tables (repeating fields and groups); particular logical anomalies
from the data, i.e., the entire primary key value, are needed to uniquely identify rows. No
non-key field determines the value of any other non-key field. (Only the primary key is the
determinant.) Though this technique makes changing and displaying information far easier
than it is under the other classical technologies, the result is both hard to understand and
inefficient to process.
The "integrity" aspect of the relational database technology consists of two basic
rules: Entity integrity and referential integrity.
"Entity integrity" means no attribute participating in the primary key of a relation is
allowed to have null values (i.e., every occurrence has values for its primary key attributes).
The primary key of a relation is composed of one or more attributes that serve as unique
identifiers for each entity occurrence.
The "referential integrity" rule states that if a foreign key FK of one relation, say R1,
matches the primary key PK of another relation, say R2, then every value of FK in R1 must
either (a) equal to the value of PK in some tuple of R2 or (b) be null (i.e., each attribute
value participating in that FK value must be null). This rule means that if one instance of an

32. 26
entity exists and refers to another entity occurrence, then the referenced entity must also
exist. For example, the values of the Customer Number attribute in the Existing Accepted
Order relation are a subset of the values of the Customer Number attribute in the Customer
relation. The relational technology can specify entity and referential integrity constraints by
the Create Table statement in the DDL.
The "data manipulation" aspect of the technology can be divided into two major
elements: Relational algebra and relational calculus.
The "Relational algebra" consists of the set operators, intersection, difference, and
union, along with special operators such as select, project, and join. Each operator takes one
or more operand and produces a new relation as a result. To query the database one writes a
sequence of relational algebra operators. The "Relational calculus" is based on first-order
logic or predicate calculus. To query the database, one writes a predicate calculus statement
that defines the desired results.
It has been shown that these two languages are equivalent in retrieval capacity.
Database languages for the relational model, such as the "Standard Query Language" (SQL),
are typically derivatives of relational calculus or relational algebra. These languages are
essentially "non-procedural" ("declarative"), i.e., operations in these languages are specified
in terms of names and values only. Users access data through a high-level, declarative,
database language. Instead of writing an algorithm to obtain desired records one at a time by
using the other classical DBMSs, i.e., programming navigational retrieval of records from
the database, the application programmer is only required to specify a predicate that
identifies the desired record(s) or combination of records. In other words, the ability to
access to the data element(s) that are needed, logically, is through the use of a combination
of its primary key value (i.e., how these relations are joined), relation(s) to which they
belong, and column name(s). A query optimizer in the RDBMSs translates the predicate
specification (queries) into an algorithm to perform database access to solve the query.
These non-procedural languages are easier to use than the navigation languages, and they
lead to higher programmer productivity and facilitate direct database access by end users.

33. 27
In summary, a RDBMS is a fundamental improvement over other classical DBMSs
because you can add, delete, change, or access data throughout an entire database by
treating it as a single set. The same search in the other classical DBMSs requires many
record-by-record comparisons and updates that can slow performance.
Accordingly, we can say that RDBMSs support high-level declarative database
languages that comprehensively support data manipulation and definition, and view
definition and manipulation, integrity constrains, transactional boundaries, authorization,
etc. SQL is the most well known of these languages.
SQL in a RDBMS environment is a user-oriented language that is executable
interactively or embedded in a host programming language. The interactive mode stands
alone. No programming other than SQL is required to access the relational database. The
embedded mode makes SQL the database programming language for a host language, e.g.,
C, FORTRAN, COBOL, and so forth. One of the difficulties of embedding SQL in another
language is that SQL is "table-oriented," while the other languages are typically "record-
oriented." SQL operates on and produces tables, and the other languages operate on one
record at a time. To handle this impedance mismatch, the concept of a cursor was
developed. A "cursor" is a logical pointer that iterates through the rows of a table. At a
particular time, the cursor points to the row on which the host language program statements
can operate. Another characteristics of SQL is that the result of one selection can be the
operand for another.
In addition to interactive and embedded SQL, many RDBMS products provide
interfaces to fourth-generation languages (4GLs) and other tools and software packages.
In summary, we can say that RDBMSs maintain the static data and provide multi
processing, full recovery, restart, referential integrity, and so on.
Most RDBMSs let on-line updating making the results of the transactions instantly
available to all users. It is also the relational database technology that allows a description to
be made exclusively in terms of logical aspects of the data. Because of the separation
between the conceptual and internal levels, effects due to changes in physical organization

34. 28
can be minimized ("physical data independence"). Similarly, because of the separation
between the external and conceptual levels, application software is insulated from changes
in the schema of a database, i.e., updating of the relations structure rarely affects the
applications ("logical data independence"). Unlike hierarchical and network DBMSs,
RDBMSs are noted for this design flexibility, their ability to be used by novice users, and
their standard database language.
Additionally, RDBMSs offer several "other capabilities" such as:
(a)Constructed algorithms to allocate tuples of relations to pages on secondary storage, i.e.,
"clustering" of data, to minimize the accessing to those tuples. For example, if you
always get specific subassemblies with the major subassemblies, you can store this
information in the same disk block.
(b)Constructed buffer management algorithms to use knowledge of access patterns for
moving pages back and forth between the disk and a main memory buffer pool.
(c)Constructed indexing techniques to provide fast associative access to single and/or group
of records specified by the values or value ranges for one or more attributes.
Some of the other features and shortcomings of relational database technology are
explained in the following subheadings of this subsection.
2. Shortcomings of the Classical Database Technologies [23, 42-46, 48, 52, 54, 58-
61]. Classical database models are not suitable candidates for database design. The major
reason for this is that all of them fail to capture much of the semantics associated with the
data. As a result, these models require extensive additional constraints to maintain the
semantic integrity of the database. Since a data structure in these models (record or relation)
may not always correspond to a single entity, these models require complex normalization
procedures to be carried out in order to ensure that there are no undesirable side effects from
an update. A consequence is that the database schemes are often difficult to design.
Both the hierarchical and network database models are biased toward the
representational aspects of the data rather than the information content of the data they
manage. Because of this, the information that can be retrieved from these databases is

35. 29
tightly constrained by the predefined relationships. In addition, severe inherent structural
constraints limit the database modeling capability and may force unnatural organization of
data.
The problem with the relational database model is that it uses a single mechanism
(the relation) to model a collection of entities, to express an association among entities, and
so forth. This semantic overloading of the relation makes it difficult for a user to determine
the meaning and purpose of a relation and obscures the meaning of a database. In addition,
the fact that interrelationships among entities are not captured in the schema, but are
formulated at execution time, implies that the users are required to perform a number of
explicit relation joins at run time. Requiring the users to perform such unnecessary joins
complicates their task considerably.
Some of the "shortcomings" of the classical database technologies are:
(a)Classical models, especially the relational model, are too simple for modeling complex
nested entities such as design objects and complex documents.
(b)Classical database models support only a limited set of "atomic" data types, such as
integer, string, etc.; they do not support general data types found in programming
languages. In particular, they do not allow the storage and retrieval of "long
unstructured data" such as images, audio, textual documents, etc.
(c)They do not include a number of frequently useful "semantic concepts" such as
generalization and aggregation relationships. This means that application
programmers must explicitly represent and manage such relationships in their
programs.
(d)The performance of the classical database technologies, especially the relational
technology, is unacceptable for various types of "compute-intensive" applications
such as simulation programs in computer-aided design environments.
(e)Application programs are implemented in some algorithmic programming language
(such as COBOL, FORTRAN, etc.) and some database language (such as SQL,

36. 30
DL/1, etc.) is embedded in it. This creates an "impedance-mismatch" problem due to
the difference between the database and programming languages.
(f)The model of transactions supported in the classical database technologies is unsuitable
for the long-duration transactions necessary in interactive, cooperative designs.
(g)Classical database technologies do not support facilities for representing and managing
the "temporal dimension" in the databases, including the notion of time and versions
of entities and schema, and change notification.
3. General Features of the Semantic Database Models [16, 19, 42, 47, 62-66]. The
deficiencies of the classical technologies, previously outlined, for database modeling have
activated intense research work in the database modeling area. This work has been known
as semantic database modeling and the resulting database model proposals are known as
"semantic database models" (e.g., the Binary Relational Model, Basic Semantic Model,
Entity-Relationship Model [ER], extended-relational model [RM/T] (such as POSTGRES,
etc.), functional data models [e.g., Functional Data Model, DAPLEX, PDM, EFDM, FDL,
etc.], Semantic Data Model [SDM], and semantic network data models [e.g., TAXIS, etc.]).
Basically, semantic database models aim to capture the meaning of data in a more or less
formal way so that database design can become systematic and the database itself can
behave intelligently. These models are characterized by having a greater expressive power
than the relational, hierarchical, and network database models.
Classical database models have only a very limited capability for expressing what
the data in the data means. They typically provide certain simple atomic data values, and
perhaps certain many-to-one relationships among those values, but very little else. For
example, it would be nice if any classical model could record that part weights and
shipment quantities are different in kind, i.e., semantically different, though they might be a
Numeric type. Although they are of the same data type, their values would not be relevant to
each other. Therefore, if a user tried to join these two on the basis of matching weights and
quantities, it would be useful if the system either queried that as an invalid join or rejected it
entirely.

37. 31
As a result, semantic database models were introduced primarily as schema design
tools. A schema could first be designed in one of the high-level semantic database models
and then translated into one of the classical DBMSs for ultimate implementation. Semantic
models provide a high level of abstraction for modeling data, allowing designers to think of
data in ways that correlate more directly to how data arise in the world. The primary
components of semantic models are the explicit representation of objects, attributes of and
relationships among objects, type constructors for building complex types, IS-A
relationships, and "derived schema components" (data values that are not actually stored in
the database, but are produced or derived whenever needed from the existing data and
relationships).
In general, most of the semantic database models describe the real world in terms of
units that are close to the concept of entity, and a few of them carry this through to make a
distinction between an entity and its names, i.e., they include the notion of object identity.
Most of the models organize the modeling units into types, and a few of them carry this
through to provide hierarchical type structure. Some models make a distinction between
attributes and relationships while some models treat both as relationships. For example, the
Salary can be treated either as an attribute of the Employee or as a relationship between the
Employee and Integer entity types. Some models make a distinction between entities and
relationships while some models force all relationships to be treated as entities in their own
right. For example, the relationship between students and courses can either be considered
as a relationship between the Student and Course entity types with Grade as a relationship,
or as an entity type Enrollment with Grade as the property of this new entity type. Some
models limit themselves to one-to-one and many-to-one relationships forcing creation of
excess entity types to model many-to-many relationships. Most of the models, however,
ignore aspects such as the provision of a set of operations, facilities to capture rules, etc.
The forerunner of semantic database models was the ER model. The ER model is
considerably simpler than the more generalized semantic model described in the following
paragraphs. It does not incorporate the notion of inheritance. In particular, the nodes in an

38. 32
ER diagram are either entity type, attribute, or relationship nodes. Figure 6.a [63] illustrates
the design of a database using the ER constructs. "Rectangles" represent "entity types,"
"ovals" represent ranges of "attributes," and "relationships" are modeled explicitly through
"diamonds." Relationships can be "one-to-many" as in Has_Orders or "many-to-one" as in
Lives_At, etc.
"Semantic network data models" use the node and link for representing the schema
(see Figure 6.b [63]). Each "node" is an "entity type," which represents a set of objects all
having the same attributes. An "attribute" is a function that can apply to an entity in the
entity type, which is similar to "instance variables." The "inheritance" relationship is
indicated with a "double arrow," "attributes" with "black arrows," and "multi valued
attributes" with "black double arrows."
Figure 6. Illustrations of some Semantic Database Models

39. 33
The "Generalized Semantic Database Model" (GSM) is a representative semantic
model that incorporates concepts from many alternative semantic models. An "oval"
represents "base types," such as integers, character strings, etc. A "triangle" represents an
"abstract entity type." Entity types can inherit attributes from one another, and a "circle"
represents an entity type, which has an "IS-A relationship" to another entity type. GSM
incorporates two constructor types: The aggregation node type and grouping node type. The
instances of an "aggregation node type" are elements of the cartesian product of its children.
"Grouping node types" have one child. An instance of a grouping node type is a set whose
elements are instances of the node type's child.
Figure 6. Illustrations of some Semantic Database Models (continued)
Entity types have attributes which can be single or multi valued functions. "Single
valued" functions are marked by "single arrowheads;" "multi valued" functions by "double
arrowheads." These functions map instances of one entity type to instances of the type

40. 34
pointed to. The "IS-A relationship" is depicted by a "thick white arrow." Finally,
"constructed types" point to their children through "dashed arrows."
Figure 7 [64] illustrates a sales office model in GSM. The salesperson inherits from
the employee and the employee inherits from the person. The Name is an aggregate. The
Age, Name, and Address are the single valued attributes of the Person entity type. A
specific set of accounts is assigned to each salesperson. Also each salesperson has a set of
orders. The Accounts and the Orders are the multi valued attributes of the Salesperson entity
type. Entity types are used for these attributes. Different constructs are used for the Name
and Address attributes. For the Name an aggregate is used, and for the Address an entity
type. The basic difference is only that elements of abstract entity types or subtypes have
separate object identities. For example, the same address can be referenced by the Address
attribute of each Person entity.
4. Shortcomings of the Semantic Database Models [42, 47, 62, 63, 65-67]. As
pointed out in many of the articles, semantic database model proposals typically use no
common terminology and are not usually defined formally. The lack of formal definitions of
these database models makes it difficult to analyze and implement them. Also, there have
not been many large-scale implementations of the semantic database models. This is
primarily because of the original goal of the most semantic database models (e.g., SDM,
ER, etc.) which was to be used as database design tools for the classical DBMSs. Because
semantic models provide the means to model data relationships accurately and naturally, the
conventional systems users are inspired to design the schemes using one of the semantic
database models. These models attempt to provide mechanisms to model information
structures and rules at an abstract level. Schemes designed using semantic database models
are expected to be translated into one of the classical DBMSs using that specific classical
DBMS's DDL for ultimate implementation. The user then retrieves, updates, and controls
the data using that specific classical DBMS's DML and DCL. This is somewhat
inconvenient and unnatural, as most of these models pay no attention to the operators or
manipulation aspects of the data they attempt to describe.

41. 35
Figure 7. An Illustration of the Generalized Semantic Database Model
On the other hand, there are several alternative semantic database modeling
proposals (e.g., functional data models) against the classical database models. However,
most of them are prototypes in research labs and are not commercialized. These models
attempt to incorporate both the data definition and manipulation capabilities into a semantic
database model using functional relationships. The most often referenced functional data
model is DAPLEX. In this model, attribute values are entities and treated as functions, and
attributes can be single or multi valued. Values are retrieved by applying functions to
entities.

42. 36
The shortcomings of the semantic database models, in terms of their modeling
capabilities, are outlined in the relevant comparison subheading.
5. Next-Generation Database Requirements [41-46, 52, 68-72]. The discovery of the
shortcomings of the classical technologies has provided impetus to pave the way for the
fifth generation of database technology. Fifth generation database technology will be
characterized by a richer database model and a richer set of DBMS facilities necessary to
meet the requirements of applications. These applications include information systems;
computer-aided design and manufacturing (e.g., CAD, CAM, etc.) applications that run on
them; knowledge-based systems (e.g., expert systems and expert system shells); multimedia
systems which deal with images, voice, and textual documents; and software engineering
and programming language systems.
The "next-generation database technology" must necessarily build on the classical
database technologies since some of the features supported in the classical database
technologies have proven to be useful for both the current classes of applications and most
of the emerging classes of applications. However, the next-generation database technology
should include additional features and incorporate solutions to many of the problems
outlined above in order to meet the requirements of the current and newly emerging
database applications.
Some of the "additional features" for the next-generation databases include:
(a)The ability to represent and manipulate complex nested objects. It should be possible to
fetch an entire complex object or a subset of it as a single unit or one component
object at a time. A complex nested object may be stored in one physical cluster for
storage and retrieval efficiency. A nested object may be a unit of concurrency
control.
(b)The ability to store and retrieve arbitrarily long and unstructured data. Effective
techniques must be supported to minimize storage space for long data and the time
for transferring long data between main memory and secondary storage. The ability
to search for desired string patterns in textual documents should be supported.

43. 37
(c)The ability to define and manipulate arbitrary and user-defined data types. The definition
and manipulation languages should extend in a natural way an underlying
programming language. Efficient storage and access methods must be supported for
these data types to expedite the processing of queries on them.
(d)The ability to represent and manage changes in the database overtime, including the
notions of time and time interval, versions of single objects, versions of complex
nested objects, and versions of the schema entities.
(e)The ability to represent and manipulate various semantic modeling concepts that are
useful for applications. One such concept is the assembly-part hierarchy in the
context of computer-aided manufacturing, compound document composition, etc.
(f)The ability to specify rules and extended constraints to support constraint management
which are necessary and basic mechanisms for supporting knowledge-based
applications.
(g)The ability to manage long-duration cooperative transactions. In interactive, cooperative
work environments, the notion of serializability is an inappropriate definition of
database consistency. A less stringent definition of database consistency, which
satisfies the practical need for flexible and concurrent sharing of common
information among multiple users, is necessary.
6. Proposed Database Technologies There are currently at least two powerful
proposed approaches to transition from the fourth generation to the fifth generation database
technology. These are extended-relational and object-oriented database technologies.
a. The Object-Oriented Database Technology [16, 17, 40, 62-64, 73, 74]. An
"object-oriented database model" is a set of object-oriented concepts for modeling data. A
survey of the semantic database models, object-oriented programming languages, and
knowledge-based languages can bring out a set of commonly accepted and fundamentally
important data modeling concepts. This set of data modeling concepts forms the "core
object-oriented database model."
A summary of the "database modeling concepts" in the core model [17] includes:

44. 38
(a)Object and Object Identifier: Any real-world entity is an "object" with which is
associated a system-wide unique "identifier."
(b)Attributes and Methods: An object has one or more "attributes" and one or more
"methods" which operate on the values of the attributes. The value of an attribute of
an object is also an object. An attribute of an object may take on a single value or set
of values.
(c)Encapsulation and Message Passing: "Messages" are sent to an object to access the
values of the attributes and the methods "encapsulated" in the object.
(d)Class: All objects which share the same set of attributes and methods may be grouped
into a "class." An object belongs to only one class as an instance-of that class. A
class is also an object; in particular, a class is an instance-of a "metaclass."
(e)Class Hierarchy and Inheritance: The classes in a system form a hierarchy or a rooted
directed acyclic graph called a "class hierarchy." For a class C and a set of lower-
level classes {Si} connected to C, a class in the set {Si} is a "specialization" of the
class C, and conversely, the class C is the "generalization" of the classes in the set
{Si}. The classes in {Si} are "subclasses" of the class C; and the class C is a
"superclass" of the classes in {Si}. Any class in {Si} inherits all the attributes and
methods of the class C and may have additional attributes and methods. All
attributes and methods defined for a class C are "inherited" into all its subclasses.
An instance of a class S is also a logical instance of all superclasses of S.
The core model includes some important "semantic relationships" among objects,
such as instance-of, aggregation, and generalization concepts; and it is further augmented
with the powerful concept of inheritance. However, the core model does not capture some
of the "semantic integrity constraints" and "semantic relationships" that are important to
many types of applications. Two of the most important of such modeling for data-intensive
applications are composite objects and versions.
A "composite object" is a heterogeneous set of objects which form a part hierarchy;
the IS-PART-OF relationship is superimposed on the aggregation relationship between an

45. 39
object and other objects it references. A composite object may be used as a unit of access in
a query and as a unit of integrity. A "versioned object" is a set of objects which are versions
of the same conceptual object. A versioned object manages the history of evolution of
versions [17].
The impetus for extending the core model with these additional modeling concepts
is simply to provide a database model which is to be directly implemented in a DBMS. The
extended model off-loads the implementation of operations embedding the database model
from the applications. The DBMS can automatically enforce any integrity constraints
associated with the operations and also achieve higher performance for the operations.
An object-oriented database model (see Figure 8 [17]) then is defined as a core
model augmented with a number of semantic integrity constraints and relationships.
Figure 8. An Illustration of an Object-Oriented Database Model
An OODBMS (such as ONTOS, ORION, GEMSTONE, OBJECTSTORE, etc.),
which allows the definition, manipulation, and control of an object-oriented database,
extends the object-oriented features with "DBMS capabilities" (which cover the classical
DBMSs features), such as [63]:

46. 40
(a)Persistence: The ability of objects to persist in different program invocations.
(b)Transactions: Execution units that are executed either entirely or not at all.
(c)Concurrency Control: The algorithms that control the concurrent execution of
transactions to guarantee the ability to serialize.
(d)Recovery: The DBMS's ability to recover from transaction, system, etc. errors.
(e)Querying: High-level declarative constructs that let users qualify what they want to
retrieve from the persistent databases.
(f)Versioning: The ability to store and retrieve multiple versions of the same persistent
database object.
(g)Integrity: The predicates that specify and define consistent states of the persistent
databases.
(h)Security: The mechanisms that control the user access rights of persistent databases.
(i)Performance Issues: The constructs and strategies used to enhance the response time and
throughput of DBMS.
For detailed information about the core model features of an object-oriented
database modeling, you should refer to Section III.A.1, An Overview of the Core Object-
Oriented Database Model Features.
b. The Extended-Relational Database Technology [23, 24, 60, 75, 76]. Criticisms of
the relational database model center around its failure to represent the real-world situations.
Some of the important "shortcomings" of the relational database model are [60]:
(a)Limited Modeling Capabilities: In the relational model both entities and relationships are
represented only by relations, which is insufficient for real-world problems. Further,
the existence of a tuple in a particular instance of a relation is used to record both
the existence and the properties of an entity. As relation may represent many things,
a high degree of understanding of the data semantics to retrieve meaningful results
from the database must be applied.
(b)Inadequate Mechanisms to Represent Entity Identity: Relationships are expressed by the
inclusion of a foreign key, which is also used to identify between differing instances

47. 41
of an entity in the attributes of an entity. This asks users to specify joins to exploit
the relationships in the data which may lie outside those relationships considered by
the database designer. Keys that may change their value also present a problem, e.g.,
both the tuple representing the entity and all tuples in which the name appears as a
foreign key need alteration.
(c)Lack of Composite Attributes: All attributes in the relational model must be "atomic,"
that is, they cannot be split into smaller parts. If the attribute hierarchy is more
complex, this will be reflected by additional complexity in the retrieval statement.
(d)Lack of Multi valued Attributes: Use of the relational model forces a degree of
artificiality into the modeling of real-world situations where repeating groups
naturally occur. For example, the solution for storing customer orders is to have an
Order and a Line Item relation (see Figure 5). The standard definition of an entity,
which needs to be distinctly identified, can only be applied loosely to an order and
its line items.
(e)Lack of Entity Subsets: It is unable to represent subtypes effectively. For example, a
Manager is a subtype of an Employee type. This means that all attributes of
employees also apply to managers. Therefore, it should be sufficient to define that
Manager is a subtype of an Employee type and therefore inherits the attributes of an
Employee. In addition, such a scheme must allow subtypes to possess attributes that
are in addition to the inherited attributes. The relational model has no mechanism
for allowing this, which hides the fact that managers are also employees.
(f)Lack of Entity Aggregation: It cannot group together entities as aggregates or subsets
without creating an extra relation, and this is not made clear in the model. Altering
an entry in the supertype has implications for a large number of entities in the
subtype, however, users are given no indication that this is the case.
(g)Confusion of Concepts of Entity and Relationship: Many-to-many relationships are
modeled through the introduction of a link relation. A mechanism is required to

48. 42
reflect the fact that this relation is not modeling an entity but instead models a
relationship.
(h)Lack of Mechanism for Identifying Transactions: Because the relational model
artificially splits data items, there is no mechanism to identify transactions. For
example, consider orders and their line items. The appropriate transaction might
include the alteration of the Line Item tuples and the Order tuple. The database does
not contain sufficient semantic information to identify that this is a transaction so
the users must ensure consistency.
(i)Inadequate Facilities for Capturing Integrity Constraints: While the relational model can
support certain types of integrity constraints, such as domain and referential
integrity, many constraints cannot be supported as standard data definitions. This
makes the applications programmer or query language user responsible for integrity
checks, which is unsatisfactory.
The "extended-relational approach" (RM/T) starts with the relational model of data
and a relational query language, and extends them in various ways to allow the modeling
and manipulation of additional semantic relationships and database facilities. POSTGRES
is the best-known DBMS based on the RM/T.
In the RM/T, some of the above criticisms are satisfied, while others remain valid.
The RM/T models the world in terms of "entities," where the entity may be abstract or
concrete. Any entity fits into an "entity type." Entities of the same type have the same
"attributes." Entities can have "subtypes" and "supertypes." Every entity occurrence is
identified by a "surrogate," which is a value automatically generated by the system, so that it
is unique. All references in the DBMS are made by surrogate values rather than by key
values. Relations can still have user-controlled keys, but this is no longer required. Users are
not allowed to see or modify the value of surrogate attributes, although they can refer to
them.
Entities are represented by E-relations and P-relations, which may be formed from
one or more relations. The "E-relations" record that entities exist. E-relations have a single

49. 43
attribute, which contains the surrogate for every entity. An entity type and subtype are also
represented by an entity relation (E-relation). When the system adds a surrogate value to the
E-relation subtype, it also places that value in the E-relation supertype. Hence, all supertype
objects including subtype objects appear in the relation, but the opposite is not true. On the
other hand, attributes of entities are represented by "property relations" (P-relations), which
associate values with the properties of entities. All of the P-relations must have a "surrogate
attribute," which identifies a tuple as belonging to a particular entity. An entity may be
modeled by more than one P-relation. The surrogate attribute is used to connect the relations
that together describe an entity.
A variety of relationships can exist among entities. Two or more entities may be
linked together by "associative entities," which represent "many-to-many" relationships.
Again as surrogate values are used to express the links between entities, the relationship is
preserved regardless of value changes. A given entity type may be a subtype of some other
types, which forms a "one-to-many" relationship. One-to-many relationships can be formed
without creating an extra entity. Finally, entities whose existence depend on the existence of
another entity, called characteristic entity, form "dependence relationships." The
"characteristic entity" is needed to define extra attributes of the "master entity;" for example,
details of Line Item entities are not meaningful unless accompanied by an Order entity.
Relationship types are also represented by E-relations and P-relations. Entity relationships
are also supported by the DBMS. This means that integrity constraints can be enforced by
the DBMS.
Additionally, a number of high-level operators are provided by the DBMS to
facilitate the manipulation of the various RM/T entities (e.g., E-relations, P-relations, etc.).
For example, it allows the definition of widely varying user views over a common
underlying database that are independent of the structure of the database.
The features of the RM/T show some of the features it possesses beyond those
found in the standard relational model. The RM/T introduces extra semantic information to
the underlying logical structure, which is explained in the following subheading.

50. 44
7. Discussions on the Object-Oriented and Extended-Relational Database
Technologies [40, 43, 45, 60, 70, 71, 74-79]. The fundamental differences between them are
the basic database model and language. The RM/T approach starts with the relational model
and a relational query language, and extends them in various ways to allow the modeling
and manipulation of additional semantic relationships and database facilities. The object-
oriented approach starts with an object-oriented database model and a language that
captures it and extends them in various ways to allow additional capabilities.
Although the RM/T does not address all the weaknesses of the relational model, it
does correct some of them without introducing a vastly more complicated model. RM/T
also does not possess the semantic richness of some other semantic models, such as SDM. It
does, however, represent a step beyond the standard relational model. In addition to the
extensions on the basic relational model by some semantic relationships and database
facilities which were explained in the above subheading, there are some other additional
"semantic integrity constraints" which the RM/T approach provides that enable to [60]:
(a)Record an entity's existence without the need to know the values of any of its attributes.
(b)Change the value of any attribute without invalidating any relationships.
(c)Rely on the DBMS to remove entities dependent on a deleted entity.
(d)Identify which entities represent many-to-many relationships.
(e)Use the subtype mechanism to group together a number of entity types.
(f)Leave concerns of referential integrity in both one-to-many and many-to-many
relationships to the DBMS.
On the other hand, the object-oriented approach is a more natural basis than the
RM/T for addressing some of the deficiencies of the classical database technologies
previously outlined (that are explained in the following subheadings). For example, these
include supporting general data types, nested objects, inheritance, and compute-intensive
applications. Besides, there are some important differences between the object-oriented
approach and RM/T. The object-oriented approach includes the object-oriented concepts,
such as encapsulation and message passing, dynamic binding, and polymorphism which are