Copyright © 2020 by the Pamantasan ng Lungsod ng Valenzuela

All rights reserved. No part of this module may be reproduced, repurposed, distributed, or transmitted in
any form or by any means including photocopying, reprinting, or other electronic or mechanical
methods without the prior written permission of PLV and the individual developers of instructional
materials (IMs) except in the case of brief quotations embodied in critical and creative reviews and
certain other noncommercial uses permitted by the Copyright Law. For permission request, address your
written correspondence whether printed or electronic to the Chair of the University Committee on
Instructional Materials Development and Evaluation at the address below:

Pamantasan ng Lungsod ng Valenzuela

Tongco St., Maysan, Valenzuela City
College: Department: Course Course Title:
Engineering and Information Information Code: Fundamentals of Database
Technology Technology IM 101 Systems
Faculty: Chairperson:
Rommel P. Apostol, MIT PATRICK LUIS M. FRANCISCO, MIT

Understanding the Flow of Data in Everyday Transactions,

A module in IM 101: Fundamentals of Database Systems
Foreword
This module aims to help students understand, familiarize, and adopt the use of fundamental data
processes and operation to utilize them in developing more efficient and secure information systems.
This module contains lessons that introduce them to the core concept of database systems and
management and answers the essential questions presented in each part of the module. The learning
outcomes from each part of the module will help the students understand the essential questions given
and at a certain point in the discussions, an evaluation will be done through the use of different
activities.
At the end of this module, the student will be able to understand the basic concepts and use of
database systems and be able to use tools and software in manipulating them.
Table of Contents
Unit Seven
Essential Questions …………………………………………………………………………….. 1
Intended Learning Outcomes …………………………………………………………………... 1
Assesment Task
Diagnostic ………………………………………………………………………………. 1
Formative ………………………………………………………………………………. 17
Summative ……………………………………………………………………………... 17
Lessons Input …………………………………………………………………………………… 1
References ……………………………………………………………………………………… 18
1

Unit Seven – Object-Oriented Data Modelling and Data Abstraction

This unit explains the step by step process in creating object-oriented data models and how to use UML
tools to create them. This unit also discusses the degrees of data abstraction and how it is important to
database design.

 Essential Question
What are the different types of Obejct-oriented data model?
How can we create a UML diagram?
What are the levels of data abstraction?

 Intended Learning Outcomes

Types of Object-Oriented Data Models and how to create them

The process of creating a UML diagram using software tools

 Diagnostic Assessment Task

At the start of the lesson the instructor will provide the following activities to gauge the students
understanding of the lesson beforehand :
1. The instructor will give one or two sample transactions that students will try to convert into an
Object-Oriented Data Model using the symbols they are familiar with

 Lessons Input
Object-Oriented Data Model (OODM)
Both data and their relationships are contained in a single structure known as an object. In turn, the
OODM is the basis for the object-oriented database management system (OODBMS). The OODM is
said to be a semantic data model because semantic indicate meaning.
The OO data model is based on the following :
1. An object is an abstraction of a real-world entity. In general terms, an object may be considered
equivalent to an ER model’s entity. More precisely, an object represents only one occurrence of
an entity.

2. Attributes describe the properties of an object. For example, a PERSON object includes the
attributes Name, Social Security Number, and Date of Birth.
2

3. Objects that share similar characteristics are grouped in classes. A class is a collection of similar
objects with shared structure(attributes) and behavior(methods). In a general sense, a class
resembles the ER model’s entity set. However, a class is different from an entity set in that it
contains a set of procedures known as methods. A class’s method represents a real-world action
such as finding a selected PERSON’s name, changing a PERSON’s name, or printing a
PERSON’s address. In other words, methods are the equivalent of procedures in traditional
programming languages. In OO terms, methods define an object’s behavior.

4. Classes are organized in a class hierarchy. The class hierarchy resembles an upside-down tree in
which each Class has only one parent. For example, the CUSTOMER class and the EMPLOYEE
class share a parent PERSON class.

5. Inheritance is the ability of an object within the class hierarchy to inherit the attributes and
methods of the classes above it. For example, two classes, CUSTOMER and EMPLOYEE, can
be created as subclasses from the class PERSON. In this case, CUSTOMER and EMPLOYEE
will inherit all attributes and methods from PERSON.

Object-oriented data models are typically depicted using Unified Modeling Language(UML) class
diagrams. Unified Modeling Language (UML) is a language based on OO concepts that describes a
set of diagrams and symbols that can be used to graphically model a system. UML class diagrams are
used to represent data and their relationships within the larger UML object-oriented system’s modeling
language.
The class diagram is a static diagram. It represents the static view of an application. The class diagram
is not only used for visualizing, describing, and documenting different aspects of a system but also for
constructing executable code of the software application.
The class diagram describes the attributes and operations of a class and also the constraints imposed on
the system. The class diagrams are widely used in the modeling of object-oriented systems because
they are the only UML diagrams, which can be mapped directly with object-oriented languages.
The class diagram shows a collection of classes, interfaces, associations, collaborations, and
constraints. It is also known as a structural diagram.

Purpose of Class Diagrams

The purpose of the class diagram is to model the static view of an application. Class diagrams are the
only diagrams that can be directly mapped with object-oriented languages and thus widely used at the
time of construction.
UML diagrams like activity diagram, sequence diagram can only give the sequence flow of the
application, however, class diagram is a bit different. It is the most popular UML diagram in the coder
community.
3

The purpose of the class diagram can be summarized as :

 Analysis and design of the static view of an application.
 Describe the responsibilities of a system.
 The base for component and deployment diagrams.
 Forward and reverse engineering.

How to Draw a Class Diagram?

Class diagrams are the most popular UML diagrams used for the construction of software applications.
It is very important to learn the drawing procedure of the class diagram.
Class diagrams have a lot of properties to consider while drawing but here the diagram will be
considered from a top-level view.
The class diagram is a graphical representation of the static view of the system and represents different
aspects of the application. A collection of class diagrams represent the whole system.
The following points should be remembered while drawing a class diagram −
 The name of the class diagram should be meaningful to describe the aspect of the system.
 Each element and their relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be identified
 For each class, the minimum number of properties should be specified, as unnecessary
properties will make the diagram complicated.
 Use notes whenever required to describe some aspect of the diagram. At the end of the drawing,
it should be understandable to the developer/coder.
 Finally, before making the final version, the diagram should be drawn on plain paper and
reworked as many times as possible to make it correct.
The following diagram is an example of an Order System of an application. It describes a particular
aspect of the entire application.
 First of all, Order and Customer are identified as the two elements of the system. They have a
one-to-many relationship because a customer can have multiple orders.
 Order class is an abstract class and it has two concrete classes (inheritance relationship)
SpecialOrder and NormalOrder.
 The two inherited classes have all the properties as the Order class. Also, they have additional
functions like dispatch () and receive ().
The following class diagram has been drawn considering all the points mentioned above.
4

Figure 7.1 Sample Class Diagram

UML Class Notation

A class represents a concept which encapsulates state (attributes) and behavior (operations). Each
attribute has a type. Each operation has a signature. The class name is the only mandatory
information.

Figure 7.2 Class Notation

Class Name:
 The name of the class appears in the first partition.

Class Attributes:
5

 Attributes are shown in the second partition.

 The attribute type is shown after the colon.
 Attributes map onto member variables (data members) in code.
Class Operations (Methods):
 Operations are shown in the third partition. They are services the class provides.
 The return type of a method is shown after the colon at the end of the method signature.
 The return type of method parameters is shown after the colon following the parameter name.
Operations map onto class methods in code

Figure 7.3 Class Operation

Class Visibility

The +, - and # symbols before an attribute and operation name in a class denote the visibility of the
attribute and operation.

Figure 7.4 Class Visibility

 + denotes public attributes or operations

 - denotes private attributes or operations
 # denotes protected attributes or operations

Parameter Directionality
6

Each parameter in an operation (method) may be denoted as in, out or inout which specifies its
direction with respect to the caller. This directionality is shown before the parameter name.

Figure 7.5 Class Parameter Direction

Perspectives of Class Diagram

The choice of perspective depends on how far along you are in the development process. During the
formulation of a domain model, for example, you would seldom move past the conceptual
perspective. Analysis models will typically feature a mix of conceptual and specification
perspectives. Design model development will typically start with a heavy emphasis on
the specification perspective, and evolve into the implementation perspective.
A diagram can be interpreted from various perspectives:
 Conceptual: represents the concepts in the domain
 Specification: the focus is on the interfaces of Abstract Data Type (ADTs) in the software
 Implementation: describes how classes will implement their interfaces

The perspective affects the amount of detail to be supplied and the kinds of relationships worth
presenting. As we mentioned above, the class name is the only mandatory information.

Figure 7.6 Class Perspective

7

Relationships between classes

UML is not just about pretty pictures. If used correctly, UML precisely conveys how code should be
implemented from diagrams. If precisely interpreted, the implemented code will correctly reflect the
intent of the designer. Can you describe what each of the relationships means relative to your target
programming language shown in the Figure below?
If you can't yet recognize them, no problem this section is meant to help you to understand UML class
relationships. A class may be involved in one or more relationships with other classes. A relationship
can be one of the following types:

Figure 7.7 Class Inheritance

Inheritance (or Generalization):

A generalization is a taxonomic relationship between a more general classifier and a more specific
classifier. Each instance of the specific classifier is also an indirect instance of the general classifier.
Thus, the specific classifier inherits the features of the more general classifier.
 Represents an "is-a" relationship.
 An abstract class name is shown in italics.
 SubClass1 and SubClass2 are specializations of SuperClass.
8

Figure 7.8 below shows an example of inheritance hierarchy. SubClass1 and SubClass2 are derived
from SuperClass. The relationship is displayed as a solid line with a hollow arrowhead that points
from the child element to the parent element.

Figure 7.8 Class Inheritance sample

Inheritance Example - Shapes

The figure below shows an inheritance example with two styles. Although the connectors are drawn
differently, they are semantically equivalent.

Figure 7.9 Class Inheritance styles in showing a relationship

9

Association

Associations are relationships between classes in a UML Class Diagram. They are represented by a
solid line between classes. Associations are typically named using a verb or verb phrase which reflects
the real-world problem domain.

Simple Association
 A structural link between two peer classes.
 There is an association between Class1 and Class2

The figure below shows an example of a simple association. There is an association that connects the
<<control>> class Class1 and <<boundary>> class Class2. The relationship is displayed as a solid line
connecting the two classes.

Figure 7.10 Class Association

Cardinality

Cardinality is expressed in terms of:

 one to one
 one to many
 many to many

Figure 7.11 Class Cardinality

10

Aggregation

A special type of association.

 It represents a "part of" relationship.
 Class2 is part of Class1.
 Many instances (denoted by the *) of Class2 can be associated with Class1.
 Objects of Class1 and Class2 have separate lifetimes.

The figure below shows an example of aggregation. The relationship is displayed as a solid line with an
unfilled diamond at the association end, which is connected to the class that represents the aggregate.

Figure 7.12 Class Aggregation

Composition
 A special type of aggregation where parts are destroyed when the whole is destroyed.
 Objects of Class2 live and die with Class1.
 Class2 cannot stand by itself.

The figure below shows an example of composition. The relationship is displayed as a solid line with a
filled diamond at the association end, which is connected to the class that represents the whole or
composite.

Figure 7.13 Class Composition

Dependency

An object of one class might use an object of another class in the code of a method. If the object is not
stored in any field, then this is modeled as a dependency relationship.
 A special type of association.
 Exists between two classes if changes to the definition of one may cause changes to the other
(but not the other way around).
 Class1 depends on Class2

The figure below shows an example of dependency. The relationship is displayed as a dashed line with
an open arrow.
11

Figure 7.14 Class Dependency

The figure below shows another example of dependency. The Person class might have a hasRead
method with a Book parameter that returns true if the person has read the book (perhaps by checking
some database).

Figure 7.15 Class Dependency

Realization

Realization is a relationship between the blueprint class and the object containing its respective
implementation level details. This object is said to realize the blueprint class. In other words, you can
understand this as the relationship between the interface and the implementing class.
For example, the Owner interface might specify methods for acquiring property and disposing of
property. The Person and Corporation classes need to implement these methods, possibly in very
different ways.

Figure 7.16 Class Realization

12

Class Diagram Example: Order System

Figure 7.17 Order System Class Diagram

Class Diagram Example: GUI

A class diagram may also have notes attached to classes or relationships.

Figure 7.18 Class Diagram with Notes

13

Where to Use Class Diagrams?

The class diagram is static and it is used to model the static view of a system. The static view describes
the vocabulary of the system.
The class diagram is also considered as the foundation for component and deployment diagrams. Class
diagrams are not only used to visualize the static view of the system but they are also used to construct
the executable code for forward and reverse engineering of any system.
Generally, UML diagrams are not directly mapped with any object-oriented programming languages
but the class diagram is an exception.
The class diagram clearly shows the mapping with object-oriented languages such as Java, C++, etc.
From practical experience, a class diagram is generally used for construction purpose.
In a nutshell, it can be said, class diagrams are used for :
 Describing the static view of the system.
 Showing the collaboration among the elements of the static view.
 Describing the functionalities performed by the system.
 Construction of software applications using object-oriented languages.

Future of Data Models

Hybrid DBMS are emerging that retain the advantages of the relational model and at the same time
provide programmers with an object-oriented view of the underlying data. These types of databases
preserve the performance characteristics of the relational model and the semantically rich programmatic
support of the object-oriented model.
SQL data services, such as Microsoft SQL Data Services (SDS) on its Azure Services Platform, are
becoming a critical component of relational database vendors’ Internet service strategies. These “cloud-
based” (that is, remotely processed and Internet-based)data services make it possible for companies of
any size to store their data in relational databases without incurring expensive hardware, software, and
personnel costs, while having access to high-end database features such as failover, backup, high
transaction rates, and global data distribution. Companies can use a “pay as you go” system based
primarily on their storage and bandwidth utilization and the features used.

Degrees of Data Abstraction

The external model is the end-users’ view of the data environment. The term end-users refer to people
who use the application programs to manipulate the data and generate information. End users usually
operate in an environment in which an application has a specific business unit focus. Companies are
generally divided into several business units, such as sales, finance, and marketing.
14

Figure 7.19 Representation of Physical, Internal and External Models

Figure 7.20 ER diagram representing an External Model

15

Because data are being modeled, ER diagrams will be used to represent the external views. A specific
representation of an external view is known as an external schema.
The conceptual model represents a global view of the entire database as viewed by the entire
organization. That is, the conceptual model integrates all external views(entities, relationships,
constraints, and processes) into a single global view of the data in the enterprise. Also known as a
conceptual schema, it is the basis for the identification and high-level description of the main data
objects.

Advantages of Conceptual model

1. Provides a relatively easily understood bird’s-eye (macro-level) view of the data environment.
2. Independent of both software and hardware. Software independence means that the model does not
depend on the DBMS software used to implement the model. Hardware independence means that the
model does not depend on the hardware used in the implementation of the model. Therefore, changes in
either the hardware or the DBMS software will not affect the database design at the conceptual level.
Generally, the term logical design is used to refer to the task of creating a conceptual data model that
could be implemented in any DBMS.

Figure 7.21 ER diagram with merged Entities from Figure 7.20

The internal Model is the representation of the database as “seen” by the DBMS. In other words, the
internal model requires the designer to match the conceptual model’s characteristics and constraints to
those of the selected implementation model. An internal schema depicts a specific representation of an
internal model, using the database constructs supported by the chosen database.
16

Figure 7.22 ER diagram from Figure 7.21 with the equivalent table definition

The physical model operates at the lowest level of abstraction, describing the way data are saved on
storage media such as disks or tapes. The physical model requires the definition of both the physical
storage devices and the (physical) access methods required to reach the data within those storage
devices, making it both software- and hardware-dependent. The storage structures used are dependent on
the software(the DBMS and the operating system) and on the type of storage devices that the computer
can handle. The precision required in the physical model’s definition demands that database designers
who work at this level have a detailed knowledge of the hardware and software used to implement the
database design.
The physical model is dependent on the DBMS, methods of accessing files, and types of hardware
storage devices supported by the operating system. When you can change the physical model without
affecting the internal model, you have physical independence. Therefore, a change in storage devices or
methods and even a change in the operating system will not affect the internal model.
17

Figure 7.23 Models by Degrees of Abstraction

 Formative Assessment Task

1. Ask students to write down what they perceived as the muddiest point in a lecture, reading,
etc. The muddiest point is something that they still do not fully understand, or are having
difficulty with. Collect responses then clarify these muddy points during the next class..

*** End of Lesson Input ***

 Summative Assessment Task

1. The instructor will give one or two transactions to students that they will convert object-
oriented data models
18

References

Garcia-Molina, H.,Ullman, J.,Widom, J. (2008). Database Systems: The Complete Book (2nd ed., pp 15-
55). Pearson