7/29/2019 10.1.1.20

1/10

An Extension to ER Model for Top-Down SemanticModeling of Databases of Applications

S K Jain1, M M Gore2, Gulab Singh3

1 CSE Department, National Institute of Technology, Hamirpur HP 177005 India

skj@recham.ernet.in 2,3 CSE Department, M N National Institute of Technology, Allahabad 211004 India

mmgore@ieee.org gulab_s15@hotmail.com

Abstract. An extension to ER (Entity Relationship) model for semantic

modeling of databases in top down manner is presented. The model proposes anew entity type called composite entity type and a table based meta construct

called tabletype relationship. A composite entity type models compositeentities, whereas a tabletype relationship is shorthand and represents a numberof relationship types. The concept of composite entity type is abstract, helps insemantic modeling, and is not required in implementation. A composite entity

type along with tabletype relationship captures semantics of the database of anapplication at a higher level of abstraction and provides a top down semanticmodeling approach in flavor of ER model.

Keywords: Semantic model, ER model, Top down model, Database design.

1. Introduction

The ER model [1] is widely accepted conceptual model for database design among

practitioners. The model has been extended by a number of researchers to capturesemantics of specific application domains. Popularity of the ER model has projected

itself as a base model for representing various application domains semantically. In

this article, we propose an extension to ER model to include a new entity type called

composite entity type and a table based meta construct called tabletype relationship.

When a composite entity type is used with the tabletype relationship, ER model

develops capability of capturing semantics of the database of an application at a

higher level of abstraction. The extended ER model becomes able to describe

relationship semantics of composite entities at both molecular and part levels in a

comprehensive and manageable manner. The proposed extension helps database

designer to manage semantic complexity of large applications in the beginning of

semantic modeling of their databases. It also offers an opportunity to database

designer to stay at one level of abstraction at a time. At any stage of conceptual

modeling, the designer can keep himself at molecular level of relationship semanticsof composite entity types by suspending to consider part level relationships

temporarily. This encourages the database designer to model database of an

application directly at a higher level of abstraction, which is more understandable and

natural. The top down semantic modeling methodology, described in this article,

1 PhD candidate with MNNIT Allahabad

7/29/2019 10.1.1.20

2/10

produces ER schema in clustered form naturally. An example, exhibiting utility of theproposed extension, is also discussed in the article.

Table 1. Explanation of terminology used in the article

Terms Explanation

1 Entity An abstract or physical object.

2 Entity type A set of similar type entities.

3 Atomic entity An entity that does not contain any other entity.

4 Atomic entity type A set of similar type atomic entities.

5 Molecular/ Composite/

Complex entity

An entity that contains other entities.

6 Molecular entity type

7 Composite entity type

8 Complex entity type

A set of similar type molecular entities.

9 Part/Constituent

entity/object

An entity that is part of some other entity. Here, other entities are

molecular entities.

10 Part entity/object type

11 Constituent entity/object

type

A set of similar type part entities.

12 Dominant entity An entity that identifies other entities on behalf of it.

13 Dominant entity type A set of similar type dominant entities.

14 Relationship Association between two or more entities.

15 Relationship type A set of similar type relationships.

16 Type of relationship One-to-one, one-to-many or many-to-many.

17 Instance level When explanation refers to individual entities.

18 Class level When explanation refers to sets.

When explanation of a relationship type includes part entity types

of a composite entity type and an atomic entity type.

When explanation of a relationship type includes part entity types

of two different composite entity types.

19 Atomic level

When explanation/description includes only atomic entity types.

20 Molecular level When explanation of a relationship type includes at least one

composite/molecular/complex entity type.

21 Higher level ofabstraction

When description of a database schema is made using fewernumbers of entity and relationship types than that of actual

numbers of entity and relationship types present.

22 Top down semantic

modeling

Continuous process of refining composite entity types into their

equivalent relationship structures until atomic level relationshipstructure of each composite entity type is obtained.

23 Intra-molecular

relationships

Described by relationship type among part entity types within a

specific molecular entity type. IM shows it in Fig. 1.

24 Inter-molecular

relationships

Described by relationship type between two or more molecular

entity types. ITM shows it in Fig. 1.

25 Molecular-atomic

relationships

Described by relationship type between a molecular entity type and

an atomic entity type. MA shows it in Fig. 1.

26 Part-atomic relationships Described by relationship type between a part entity type of amolecular entity type and an atomic entity type. PA shows it in

Fig. 1.

27 Part-part relationships Described by relationship type between part entity types of two ormore molecular entity types. PP shows it in Fig. 1.

28 Inter-atomic

relationships

Described by relationship type between two or more atomic entity

types. IA shows it in Fig. 1.

7/29/2019 10.1.1.20

3/10

2. Motivation

We have devised a methodology for ER schema compression/abstraction [2]. The

methodology uses purely syntactic criterion based on use of tables for schema

abstraction. This success intuitively appealed us to use tables judiciously somewhere

in database modeling process. Present work uses tables to extend ER model such that

the extended model captures semantics of the database of an application in top down

manner.

3. Proposed Extension to ER Model

Table 1 describes terminology used in the article. Fig. 1 exhibits structure of

relationship types of the entity types present inside a molecular entity type and outside

with other molecular and atomic entity types. Acronyms used in Fig. 1 are describedin Table 1 from serial no. 23 to 28. We extend ER model to include a new entity type

called composite entity type and a table based meta construct called tabletype

relationship. A composite entity type models composite entities at a higher level of

abstraction such that an ER diagram exhibits its detail separately. Tabletype

relationship is a meta construct that replaces a number of relationship types in schema

diagram by itself and mentions them in a table separately. The name of tabletype

relationship in schema diagram refers to this table, where details are mentioned. The

notation for composite entity type and tabletype relationship is shown in Fig. 2. A

tabletype relationship exhibits relationship types between an atomic entity type and

part entity types of a composite entity type as shown in Fig 3. In Fig. 1, relationship

PA exhibits the same. A tabletype relationship can also represent relationship types

between part entity types of two different composite entity types as shown in Fig. 4.

The same is also shown by relationship PP in Fig. 1. Therefore, any application thatconsists of atomic entities, composite entities, and relationships among them can be

modeled at a higher level of abstraction using composite entity types, tabletype

relationships, and other constructs of ER model as shown in Fig. 5.

Molecular entity typeMolecular entity type

Atomic entity type

Fig. 1. Relationship types present in schema of the database of an application

PA

ITM

MA

IA

PP

IMIM

IM

7/29/2019 10.1.1.20

4/10

(Composite entity type) (Tabletype relationship)

Fig. 2. Notation for composite entity type and tabletype relationship

An ER diagram Composite Composite

forming entity entity

composite type 1 type 2

entity type

to be represented by tabletype relationship to be represented by tabletype relationship

Fig. 3. Relationship types between part entity types Fig. 4. Relationship types between part

of a composite entity type and an atomic entity type entity types of two composite entity types

ER diagram describing

composite entity typeEc

Fig. 5. Database schema prepared using Fig. 6. ER diagram describing compositecomposite entity type and tabletype relationship entity type Ec

In Fig. 5, relationship type R captures relationship semantics between a composite

entity type EC and an atomic entity type E at molecular level, whereas tabletyperelationship TR captures relationship semantics between constituent entity types of

composite entity type EC and an atomic entity type E. Here, constituent entity types

may further be made of composite entity types. Fig. 6 represents ER diagram

describing composite entity type EC shown in Fig. 5. Table 2 describes details of

tabletype relationship TR shown in Fig. 5. The first column of Table 2 includes the

names of those part entity types of composite entity type E C that participate in

relationships with atomic entity type E. The names of relationship types from entity

type E to part entity types mentioned in column 1 are written in column 2. The third

column of the table describes type of relationship, i.e., one-to-one, one-to-many or

many-to-many from entity type E to part entity types mentioned in column 1. The

fourth column of the table represents names of attributes of relationship types

mentioned in column 2. Complete interpretation of Fig. 5 is made along with Fig. 6

and Table 2, where details of EC and TR are mentioned. Since Table 2 describesdetails of tabletype relationship TR, it is named as Table TR. In fact, E C is one entity

type present in ER diagram (Fig. 6) such that other constituent entity types are

identified on behalf of it. It is just like dominant entity type in Fig. 6. Therefore, in

Fig. 5, EC should have same value domains for key and other attributes as one entity

type in ER diagram (Fig. 6) has. If tabletype relationship exhibits relationship types

between part entity types of two different composite entity types, the format of table

EC

TR

R E

7/29/2019 10.1.1.20

5/10

for tabletype relationship will be as shown by Table 3. Table 4, named as RemainingRelationships Table, is used to describe (1) relationship types between entity types

that are not in immediate level of refinement in the hierarchy of top down modeling;

and (2) relationship types between part entity types of two compositeentity types thatbelong to two different ER diagrams.

Table 2. Table used to describe tabletype relationship TR

Table TR1 2 3 4

Names of part entity types of

composite entity type EC that

participate in relationship types

mentioned in column 2 with

atomic entity type E

Names of relationship types from

entity type E to part entity types

mentioned in column 1

Type of

relationship

Attributes of

relationship types

mentioned in

column 2

-

-

-

-

-

-

-

-

Table 3. Table to describe tabletype relationship, when part entity types belong to two differentcomposite entity types

Table 4. Table to describe relationship types, which could not be represented by tabletype

relationships

Remaining Relationship Table

4. Modeling Methodology

The proposed model captures semantics of more general form of a composite entity

which we state as any part of application domain that makes a meaningful unit can

be treated as a composite entity at higher level of abstraction. We suggest following

steps for semantic modeling of databases of applications:

1. Identify atomic entity types and composite entity types in the application at

highest or reasonable higher level of abstraction. Here, highest or reasonable

1 2 3 4 5

From To

Names of part entitytypes of composite

entity type CE1

Names of part entitytypes of composite

entity type CE2

Names of relationship typesfrom part entity type of CE1to part entity type of CE2 asmentioned in column 1 and 2

Type ofrelationship

Attributes ofrelationship typesmentioned incolumn 3

--

--

--

--

1 2 3 4 5 6 7 8 9

From To

Namesofpart/com

positeentitytypes

Name ofimmediatecomposite

entity type ifpresent

FigureNo. orPage No.

forreference

Names ofpart/composite

entitytypes

Name ofimmediatecomposite

entity type ifpresent

FigureNo. orPage

No. forreference

Names ofrelationshiptypes from part

entity typesmentioned incolumn 1 topart entity typesmentioned incolumn 4

TypeofRelatio

nship

Attributesofrelationsh

ip typesmentioned incolumn 7

7/29/2019 10.1.1.20

6/10

higher level may be decided based on the argument of seven, plus or minus two[3]; that is, on average schema should have seven items (sum of numbers of entity

types, relationship types, and tabletype relationships).

2. Prepare detailed ER diagram for each composite entity type.

3. Identify atomic and molecular level relationship types in the application, and

assign semantic names to tabletype relationships.

4. Prepare details of each tabletype relationship.

5. If there is any composite entity type in detailed ER diagrams of composite entity

types as identified in step 1, refine composite entity types using step 2 to 4 till

atomic level description of each composite entity type is obtained.

6. Examine the need of Remaining Relationships Table; if yes, prepare its detail.

7. Review design.

5. An Example

This section explains an example of applying our proposed semantic modeling

methodology. Here, we shall use notation for ER diagrams as used by Korth &

Silberschatz in [4]. In [4], cardinality constraint usesLook Across notation; cardinality

between an entity and relationship types is represented by either a directed line

(arrow) for one-side or an undirected line for many-side. Now, we model our institute

semantically. In ER diagrams, we shall not exhibitattributes of entity types becauseof clarity in expressiveness. We shall also not mention names of most of the

relationship types because of limitation of space. We describe modeling activities in

steps as follows:

1. We model institute at a very high level of abstraction using two composite entity

types, three atomic entity types, and relationship types among them. Fig. 7

represents its ER diagram.

Fig. 7. Schema diagram of the example

2. We refine composite entity types named Building and People, shown in Fig. 7,

into their relationship structures. Fig. 8 and 9 represent detailed ER diagrams of

these composite entity types.

3. We prepare Table 5 to describe details of tabletype relationship named Peoplerelated to shown in Fig. 7. At the first column of the table, the part entity types

that are of composite entity type have been distinguished by adding C in brackets

along with their names. We have not shown names of relationship types at third

column and names of attributes at fifth column in the table due to clarity in

expressiveness.

Building PeoplePeoplerelated

toRoad Ground

Main Road Link Road

IS A

7/29/2019 10.1.1.20

7/10

Fig. 8. ER diagram describing composite entity type Building shown in Fig. 7

Fig. 9. ER diagram describing composite entity type People shown in Fig. 7

Table 5. Table describing details of tabletype relationship named People related to shown inFig.7

People related to

4. We further refine composite entity types named Department, Hostel, Staff

Quarter Block, and Shopping Center shown in Fig. 8 and exhibit them by

individual ER diagrams in Fig. 10, 11, 12, and 13. Here, we are not showing

attributes of entities and names of relationships due to clarity in expressiveness.

1 2 3 4 5

From People

Names of part entity

types of composite entity

type Building

Names of part

entity types of

composite

entity type

People

Names of relationship types

from part entity type of

composite entity type

Building to part entity type

of composite entity type

People as mentioned in

column 1 and 2

Type of

relationshi

p

Attributes of

relationship

types

mentioned in

column 3

Department (C)

Department (C)

Department (C)

Department (C)

Hostel (C)

Hostel (C)

Staff Quarter Block (C)

Staff Quarter Block (C)

Library

Shopping Center (C)

Dispensary

Power Sub Station

Teacher

Student

Technician

Clerical

Student

Clerical

Teacher

Others

Others

Others

Others

Others

-

-

-

-

-

-

-

-

-

-

-

1-to-n

1-to-n

1-to-n

1-to-n

1-to-n

1-to-n

1-to-n

1-to-n

1-to-n

1-to-n

1-to-n

1-to-n

-

-

-

-

-

-

-

-

-

-

-

Building

IS A

DispensaryPowerSubStation

Department Hostel Staff

QuarterBlock

ShoppingCentreLibrary

Teacher

People

IS A

Student Technician Clerical Others

7/29/2019 10.1.1.20

8/10

5. We make Remaining Relationships Table to represent relationship typesbetween entity types (1) which are not in immediate level of refinement in thehierarchy of top down modeling; (2) that belong to two composite entity types,whose details are shown in two different ER diagrams. Table 6 representsRemaining Relationships Table. Sub columns in Table 6 contain referenceinformation for entity types participating in relationships.

Fig. 10. ER diagram describing composite entity type Department shown in Fig. 8

Fig. 11.ER diagram describing composite entity type Hostel shown in Fig. 8

Fig. 12. ER diagram describing composite Fig. 13. ER diagram describing compositeentity type Staff Quarter Block shown entity type Shopping Center shown inin Fig.8 Fig.8

Department

PartOf

Room

Class Room Faculty Room Head Room

LabDepartmental

Library

IS A

Seminar Room Department Office

Room

Guest Room

Hostel

Student Room Other RoomCommon RoomMess Worker Room

Mess Hall

Part

Of

Ground

IS A

Staff Quarter Block Quarter Shopping Center Shop

7/29/2019 10.1.1.20

9/10

Table 6. Table describing relationship types (1) which are not in immediate level of refinementin the hierarchy of top down modeling; (2) between part entity types of two composite entity

types that belong to two different ER diagrams

Remaining Relationship Table

6. Analysis of Proposed Extension and Related WorkThe lack of semantics in relational model has compelled database researchers to

develop ER model for representing databases in better understandable form. A good

model should support modeling constructs required to represent semantics of

application domain as close as possible to reality with least possible efforts, and this

argument appears true in case of ER model. Type constructs (entity type and

relationship type) of ER model directly capture semantics of entities and relationships

among them, as they occur naturally in real world. When number of entities in

application domain becomes too large, people used to combine them in meaningful

units for better comprehension, communication, and documentation. Intuitively, this

reasoning supports considering composite entities to occur naturally at a higher level

of abstraction from standpoint of human understanding. Therefore, any model that has

modeling construct to represent composite type entities will certainly ease modeling

effort. The inclusion of aggregation and generalization/specialization in EER and OO

models also appears valid based on this principle. Modeling concepts of composite

entities are already well known in semantic modeling [5], particularly in CAD/CAM,

engineering applications, VLSI design, geometric modeling etc. A composite entity is

an atomic object at higher level, whereas at lower level it is not printable and

exhibited by relationship structure that composes it. A composite entity is constructedusing aggregation/composition relationship construct. The relationship structure of a

composite entity type may also include association and generalization/specialization

relationship constructs. In this article, the proposed composite entity type is a type

definition. The use of composite entity type with table-based meta construct eases

modeling effort and provides top down semantic modeling methodology for databases

in flavor of ER model.

1 2 3 4 5 6 7 8 9

From To

S

N

Names of part /compositeentity types

Name ofimmediatecomposite

entity type ifpresent

FigureNo. forreferen

ce

Names ofpart /composite

entity types

Name ofimmediate

composite entitytype ifpresent

FigureNo. forreferen

ce

Names ofrelationshiptypes from partentity typesmentioned in

column 1 topart entity typesmentioned incolumn 4

TypeofRelationship

Attributes ofRelationshiptypes

mentioned incolumn 7

1

2

34

5

6

7

-

Faculty

Room

Head Room

LabDepartmental

Library

Student

Room

Quarter

Shop

-

Department

Department

DepartmentDepartment

Hostel

Staff Quarter

Block

Shopping

Centre

-

10

10

1010

11

12

13

Teacher

Teacher

TechnicianClerical

Student

People

Others

-

People

People

PeoplePeople

People

People

People

-

9

9

99

9

9

9

-

-

--

1-to-1

1-to-1

n-to-11-to-1

1-to-n

1-to-1

1-to-1

-

-

--

-

7/29/2019 10.1.1.20

10/10

To our best knowledge, UML (Unified Modeling Language) is only availablemodeling language, which supports composite object type using composite class. The

concept of top-down modeling is well known in software engineering in general, but

the same is not addressed for semantic modeling of databases except [6]. In

comparison to work described in [6], our model (1) captures semantics of the database

of an application in top down manner, even if related entities belong to non-adjacent

levels of refinement in hierarchy; (2) represents atomic and molecular level

relationship semantics in one schema; (3) has inbuilt, natural clustering of entire

schema in pieces; (4) up to some extend steps 2, 3, and 4 of the modeling

methodology can be carried out in parallel. Up to some extend, our model can also be

compared with Higher-order Entity-Relationship Model (HERM) [7]. We believe

that our proposed model is superior to HERM since it preserves distinction between

entity and relationship types; whereas HERM treats entity types as 0-order

relationship types. At present, our model has limitation as it addresses only binaryrelationships. The present work can be extended to address issue of higher order

relationships.

7. ConclusionIn present paper, we have proposed an extension to ER model to capture semantics of

databases of applications in top down manner. The model proposes a new entity type

called composite entity type and a table based meta construct called tabletype

relationship. Traditionally, large database applications are modeled using EER or OO

model, and bottom up clustering methodologies are applied to make database schema

maintainable, comprehensible, and documental. Our proposed model has natural

solution for clustering of schema and automatically generates resultant schema in

manageable, comprehensive, and documental form. In our opinion, proposed top

down modeling methodology in flavor of widely used ER model will certainly easemodeling process of large and complex databases e.g. database for keeping details of

a building or town in architectural engineering. The model can also use readymade

schema constructs from library of schemas instead of starting modeling activities for

the database of an application from scratch.

References1. Chen P P The Entity Relationship Model- Towards a Unified View of Data Transactions

on Database Systems, Vol. 1, No. 1, 1976, pp 9-36.

2. Jain S K, Singh G, Gore M M Entity Relationship Schema Compression Technique Basedon Use of Tables 6th International Conference on Information Technology CIT 2003, Dec22-25, 2003 at Bhubaneshwar India, pp 455-460.

3. Miller George A The Magical Number Seven, Plus or Minus Two: Some Limits on Our

Capacity for Processing Information The Psychological Review, 1956, Vol. 63, pp 81-97.

4. Korth H and Silberschatz A Database System Concepts 2ed., McGraw Hill, 1991.5. Batory D S, Kim Won Modeling Concepts for VLSI CAD Objects ACM Transactions on

Database Systems, Vol. 10, No. 3, Sept 1985, pp 322-346.6. Troyer Olga De, Janssen Rene On Modularity for Conceptual Data Models and the

Consequences for Subtyping, Inheritance & Overriding Proceedings of ICDE, 1993, pp678-685.

7. Thalheim Bernhard Entity-Relationship Modeling Foundations of Database TechnologySpringer, 2000.