DATABASE DESIGN AND

MANAGEMENT UNIT I: CONCEPTUAL DATA MODELING

Database environment –Database system development lifecycle – Requirements collection –

Database design --Entity-Relationship model – Enhanced-ER model – UML class diagrams.

INTRODUCTION

Data:Raw fact i.e unprocessed data.

Eg: Suresh,25,Chennai

Information: Processed data.

Eg: The age of suresh is 25

Database:

A Database is a collection of related data organized in a way that data can be easily accessed,
managed and updated. Any piece of information can be a data, for example name of your school.
Database is actualy a place where related piece of information is stored and various operations can
be performed on it.

Database Management System (DBMS): The software which is used to manage database is
called Database Management System (DBMS). For Example, MySQL, Oracle etc. are popular
commercial DBMS used in different applications.

DBMS allows users the following tasks:

Data Definition: It helps in creation, modification and removal of definitions that define the organization of
data in database.
Data Updation: It helps in insertion, modification and deletion of the actual data in the database.

Data Retrieval: It helps in retrieval of data from the database which can be used by applications for various
purposes.
User Administration: It helps in registering and monitoring users, enforcing data security, monitoring
performance, maintaining data integrity, dealing with concurrency control and recovering information
corrupted by unexpected failure.

Database Applications:

1. Banking: all transactions

2. Airlines: reservations, schedules
3. Universities: registration, grades
4. Sales: customers, products, purchases
5. Online retailers: order tracking, customized recommendations
6. Manufacturing: production, inventory, orders, supply chain
 7. Human resources: employee records, salaries, tax deductions

DBMS Architecture
o The DBMS design depends upon its architecture. The basic client/server architecture is
used to deal with a large number of PCs, web servers, database servers and other
components that are connected with networks.
o The client/server architecture consists of many PCs and a workstation which are connected
via the network.
o DBMS architecture depends upon how users are connected to the database to get their
request done.

Types of DBMS Architecture

Database architecture can be seen as a single tier or multi-tier. But logically, database architecture
is of two types like: 2-tier architecture and 3-tier architecture.

1- Tier Architecture
o In this architecture, the database is directly available to the user. It means the user can
directly sit on the DBMS and uses it.
o Any changes done here will directly be done on the database itself. It doesn't provide a
handy tool for end users.
o The 1-Tier architecture is used for development of the local application, where
programmers can directly communicate with the database for the quick response.
o Tier Architecture in DBMS is the simplest architecture of Database in which the client,
server, and Database all reside on the same machine. A simple one tier architecture example
would be anytime you install a Database in your system and access it to practice SQL
queries. But such architecture is rarely used in production.
2- Tier Architecture
o The 2-Tier architecture is same as basic client-server. In the two-tier architecture,
applications on the client end can directly communicate with the database at the server side.
For this interaction, API's like: ODBC, JDBC are used.
o The user interfaces and application programs are run on the client-side.
o The server side is responsible to provide the functionalities like: query processing and
transaction management.
o To communicate with the DBMS, client-side application establishes a connection with the
server side.
o A 2 Tier Architecture in DBMS is a Database architecture where the presentation layer runs
on a client (PC, Mobile, Tablet, etc.), and data is stored on a server called the second tier.
Two tier architecture provides added security to the DBMS as it is not exposed to the end-
user directly. It also provides direct and faster communication.

Fig: 2-tier Architecture

In the above 2 Tier client-server architecture of database management system, we can see that one
server is connected with clients 1, 2, and 3.

3- Tier Architecture
o The 3-Tier architecture contains another layer between the client and server. In this
architecture, client can't directly communicate with the server.
o The application on the client-end interacts with an application server which further
communicates with the database system.
o End user has no idea about the existence of the database beyond the application server. The
database also has no idea about any other user beyond the application.
o The 3-Tier architecture is used in case of large web application.
o 3-Tier database Architecture design is an extension of the 2-tier client-server architecture.
A 3-tier architecture has the following layers:

 Presentation layer (your PC, Tablet, Mobile, etc.)

 Application layer (server)
 Database Server
The Application layer resides between the user and the DBMS, which is responsible for
communicating the user’s request to the DBMS system and send the response from the DBMS to
the user. The application layer(business logic layer) also processes functional logic, constraint,
and rules before passing data to the user or down to the DBMS.

The goal of Three Tier client-server architecture is:

 To separate the user applications and physical database
 To support DBMS characteristics
 Program-data independence
 Supporting multiple views of the data
 Fig: 3-tier Architecture

Three schema Architecture

o The three schema architecture is also called ANSI/SPARC architecture or three-level
architecture.
o This framework is used to describe the structure of a specific database system.
o The three schema architecture is also used to separate the user applications and physical
database.
o The three schema architecture contains three-levels. It breaks the database down into three
different categories.

DATABASE ENVIRONMENT
One of the primary aims of a database is to supply users with an abstract view of data,
hiding a certain element of how data is stored and manipulated. Therefore, the starting point
for the design of a database should be an abstract and general description of the information
needs of the organization that is to be represented in the database. And hence you will require
an environment to store data and make it work as a database.
VIEWS OF DATA/DATA ABSTRACTION:
A major purpose of a database system is to provide users with an abstract view of data. Ie., the
system hides certain details of how the data are stored and maintained.
Three Schema Architecture:
Separates the user applications and physical database. Schemas can be defined in three
levels:
(i) Internal Level:
 It has an internal schema which describes physical storage structure of the database.
 How the data are actually stored uses physical model
 describes the complete details of data storage and access paths for the
database.e.g., customer

(ii) Conceptual Level:

 It has an conceptual schema which describes the structure of whole database

 What data are stored and what relationships exist among data.
 Uses high level or implementational data model.
 Hides the details of physical storage structures and
describes datatypes, relationships, operations and
e.g constraints.
:

typecustomer =
record customer_id :
string;
customer_name :
string;
customer_city
 (iii) External or View Level:
 includes a number of external schemas or views.
 Each external schema describes the part of the database and hides the rest.
 Uses high level or implementation data
model. such as an employee’s salary.

Instances and Schemas

The state of the database changes over time as information is inserted and deleted by the
users. Instance:
The collection of information stored in the database at a particular moment is called Instance of
the database.
Schema:
The overall design of the database is called the database schema.
When you talk about the database, you must distinguish between the database schema, which is
the logical blueprint of the database, and the database instance, which is a snapshot of the data in
the database at a given instant in time. The concept of a relation corresponds to the programming
language notion of a variable. In contrast, the concept of a relation schema corresponds to the
programming languages' notion of the type definition. In other words, a database schema is a
skeletal structure that represents the logical view of the complete database. It describes how the
data is organized and how the relations among them are associated and formulates all the
constraints that are to be applied to the data.

In general, a relation schema consists of a directory of attributes and their corresponding domain.
Some Common Relational Model Terms

 Relation: A relation is a table with columns and rows.

 Attribute: An attribute is a named column of a relation.
 Domain: A domain is the set of allowable values for one or more attributes.
 Tuple: A tuple is a row of a relation.

A database schema can be divided broadly into two categories −

 Physical Database Schema − This schema pertains to the actual storage of data and its
form of storage like files, indices, etc. It defines how the data will be stored in a secondary
storage.

 Logical Database Schema − This schema defines all the logical constraints that need to be
applied on the data stored. It defines tables, views, and integrity constraints.

A database environment is a collective system of components that comprise and regulates the
 group of data, management, and use of data, which consist of software, hardware, people,
techniques of handling database, and the data also.
Here, the hardware in a database environment means the computers and computer peripherals
that are being used to manage a database, and the software means the whole thing right from
the operating system (OS) to the application programs that include database management

software like M.S. Access or SQL Server. Again the people in a database environment include
those people who administrate and use the system. The techniques are the rules, concepts, and
instructions given to both the people and the software along with the data with the group of
facts and information positioned within the database environment.

Components of Database System Environment

Every system environment is made up of certain components that help the system to get
organized and managed. Even the database system environment is made up of the following
components:

Componenets of Database System

The database system can be divided into four components.

Users: Users may be of various type such as DB administrator, System developer and End
users.
Database application : Database application may be Personal, Departmental, Enterprise and
Internal
DBMS: Software that allow users to define, create and manages database access, Ex: MySql,
Oracle etc.
Database: Collection of logical data.
1. Hardware
The hardware component of the database system environment includes all the physical
devices that comprise the database system. It includes storage devices, processors, input and
output devices, printers, network devices and many more.
2. Software
The software component of the database environment includes all the software that we require
to access, store and regulate the database. Like operating systems, DBMS and application
programs and utilities. The operating system invokes computer hardware, and let other
software runs. DBMS software controls and regulates the database. The application program
and utilities access the database and if required you can even manipulate the database.
3. People
If talk of the people component then it will include all the people who are related to the
database. There may be a group of people who will access the database just to resolve their
queries i.e. end-user, there may be people that are involved in designing the database i.e.
database designer.
There are four distinct types of people that participate in the DBMS environment: data
and database administrators, database designers, application developers, and the end-
users.
Some may be involved in designing the applications that will have an interface through which
data entry is possible i.e. database programmer and analyst and some may also be there to
monitor the database i.e. database administrator.
4. Procedures
The procedure component of the database environment is nothing but the function
that regulates and controls the use of the database.
5. Data
Data component include a collection of related data which are the known fact that can
be recorded and it has an implicit meaning in the databsae.
System Utilities
Database system utilities are the tools that can be used by the database system administrator
to control and manage the database system.
System Utilities
Database system utilities are the tools that can be used by the database system administrator
to control and manage the database system.
1. Loading Utility
Loading database utility helps in loading the database file into the database. It efficiently
reformats the current format of data files to the format that is required by the destination
database file structure. Some loading programs or tools are specially designed for loading data
from one DBMS to another.
If you provide source database storage description and target database storage description to
these loading tools then it will automatically reformat the data files to target database storage
description.
2. Backup Utility
The backup utility in the database environment helps in creating a backup copy of the entire
database. Generally, the entire data of the database is copied to mass storage and we refer to it
as a backup copy. This backup copy can be used when there is a system failure or storage of
your system is corrupted.
You can always choose incremental backups which only record the changes from the previous
backup. Though the incremental backup requires a more complex algorithm it saves more
space as compared to regular backup.
3. Database Storage Reorganization Utility
Sometimes we need to relocate the set of database files to a different location. The database
storage reorganization utility helps to relocate and organize the database files to a different
location and it also produces a new access path to access the files from its new location.
4. Performance Monitoring Utility
Performance monitoring utility monitors the usage of the database by its user and provides
statistics for the same to the database administrator (DBA). The statistics provided by the
utility helps the DBA to decide whether it is required to reorganize the data files, whether
 there is a need to add new indexes or not, whether some indexes to the files must be dropped
to improve the performance of the database system.
There are more utilities in the database environment that help in sorting the database file on
some basis, handling data compression on the large databases, monitoring the user’s access to

the database and many more.

2. DATABASE SYSTEM DEVELOPMENT

LIFECYCLE Explanation:1

As a database system is a primary element of the more extensive organization-

wide information system, the database system development life cycle is inherently
connected with the life cycle of the information system. The stages of the
database system development lifecycle are shown in the figure below:
Database System Development Lifecycle
 Database planning
 System definition
 Requirements collection and analysis
 Database design (conceptual, logical, physical)
 DBMS selection (optional)
 Application design
 Prototyping (optional)
 Implementation
 Data conversion and loading
 Testing
 Operational maintenance

Database Planning – Mission Statement

An essential first step in database planning is to define the mission statement for the database
system. The mission statement describes the primary aims of the database system. Those are
driving the database project within the organization that generally defines the mission statement.
A mission statement helps to simplify the purpose of the database system and provide a clearer
path towards the efficient and effective creation of the required database system.

It is the management activities that permit the stages of the database system development life
cycle to be realized as efficiently and effectively as possible.

Database planning must be integrated with the overall IS strategy of the

organization. There are three main issues involved in formulating an IS strategies

which are:

 Identification of enterprise plans and goals with the subsequent purpose of

information systems requirements
 Evaluation of current information systems to find out existing strengths and weaknesses
 Appraisal of IT opportunities that might yield aggressive advantage
 Ex.
―The purpose of our HW database system is to maintain the data that is used to
support hotel room rentals
 Once mission statement is defined, mission objectives are defined which should identify
a particular task that the database must support.
Ex.
To maintain (insert, update, delete) data on the hotels, rooms, guests, and bookings.

System Definition
 Describes scope and boundaries of database system and the major user views.
 User view defines what is required of a database system from the perspective of:
 – a particular job role (such as Manager or Supervisor) or
– enterprise application area (such as marketing, personnel, etc.).

Representation of a Database System with Multiple User View

Requirements Collection and Analysis

Ø Get user requirements - collect and analyze information about the part of organization to
be supported by the database system.
Ø These requirements/features for the new database system are described in documents known
as the requirements specifications.
Ø Many techniques for gathering this information (fact-finding techniques)
Database Design

Database Design: Creating a design for a database that will support the mission statement
and mission objectives.
Ø Data Modeling is in the Database Design Phase.
Ø Building data model requires answering questions about entities, relationships, and
attributes. Three phases of database design:
– Conceptual database design
– Logical database design
– Physical database design.
Conceptual Database Design

Process of constructing a model of the data used, independent of all physical

considerations. Ø Conceptual data model is built using the information in users’
requirements specification. Ø Ex. ER Diagram
Logical Database Design
Conceptual data model is independent of all physical considerations, a logical model is
derived knowing the underlying data model of the target DBMS.
Ø Ex. relational data model, normalization

Physical Database Design

The physical design of the database specifies a description of the physical configuration of the
database, such as the tables, file organizations, indexes, security, data types, and other
parameters in the data dictionary.

Ø To describe how we intend to physically implement the logical database design.

DBMS Selection
Selection of an appropriate DBMS to support the database system (if none exist).
Ø Undertaken at any time prior to logical design provided sufficient information is
available regarding system requirements.
Ø Check off DBMS features against requirements.
Ø Some DBMS examples include MySQL, Microsoft Access, SQL Server, Oracle

Example DBMS Evaluation Features

Application Design
Design of user interface and application programs that use and process the
database. Ø Database design and application design are parallel activities.
Prototyping (Optional)

Building working model of a database

system. Ø Does not contain all the required
features.
Ø Purpose
– to identify features of a system that are inadequate;
– to suggest improvements or even new features;
– to clarify the users’ requirements;
– to evaluate feasibility of a particular system design.

Implementation
Physical realization of the database and application designs.
– Use DDL to create database schemas and empty database files
– Use DDL to create any specified user views.

Data Conversion and Loading

Transferring any existing data into new database and converting any existing applications to run
on new database.
Ø Only required when new database system is replacing an old system.
– DBMS normally has utility that loads existing files into new database.
Ø May be possible to convert and use application programs from old system for use by
new system.

Testing
Process of running the database system with the intent of finding
errors. Ø Use carefully planned test strategies and realistic data.
Ø Demonstrates that database and application programs appear to be working according
to requirements.

Operational Maintenance
Process of monitoring and maintaining database system following
installation. Ø Monitoring performance of system.
– if performance falls, may require tuning or reorganization of the
database. Ø Maintaining and upgrading database system (when required).
Incorporating new requirements into database application.

Explanation: 2

The different phases of database development life cycle (DDLC) in the Database
Management System (DBMS) are explained below −

● Requirement analysis.
● Database design.
● Evaluation and selection.
● Logical database design.
 ● Physical database design.
● Implementation.
● Data loading.
● Testing and performance tuning.
● Operation.
● Maintenance.

Now, let us understand these phases one by one.

Requirement Analysis
The most important step in implementing a database system is to find out what is needed i.e
what type of a database is required for the business organization, daily volume of data, how
much data needs to be stored in the master files etc.

In order to collect all this information, a database analyst spends a lot of time within the
business organization talking to people, end users and getting acquainted with the day-to-day
process.

Database Design
In this phase the database designers will make a decision on the database model that perfectly
suits the organization’s requirement. The database designers will study the documents
prepared by the analysis in the requirement analysis stage and then start development of a
system model that fulfils the needs.

Evaluation and selection

In this phase, we evaluate the diverse database management systems and choose the
one which perfectly suits the requirements of the organization.
In order to identify the best performing database, end users should be involved.

Logical database design

Once the evaluation and selection phase is completed successfully, the next step is logical
database design.
 This design is translated into internal model which includes mapping of all objects i.e
design of tables, indexes, views, transaction, access privileges etc.,

Physical Database Design

This phase selects and characterizes the data storage and data access of the database. The data
storage depends on the type of devices supported by the hardware, the data access methods.
Physical design is very vital because of bad design which results in poor performance.

Implementation
Database implementation needs the formation of special storage related
constructs. These constructs consist of storage groups, table spaces, data files,
tables etc.

Data Loading
Once the database has been created, the data must be loaded into the
database. The data required to be converted, if the loaded date is in a
different format.

Operations
In this phase, the database is accessed by the end users and application programs. This stage
includes adding of new data, modifying existing data and deletion of absolute data. This
phase provides useful information and helps management to make a business decision.

Maintenance
It is one of the ongoing phases in DDLC.
The major tasks included are database backup and recovery, access management, hardware
maintenance etc.

3.REQUIREMENT COLLECTION
Before we can effectively design a database, we must know and analyze the expectations of the
users and the intended uses of the database in as much detail as possible. This process is
called requirements collection and analysis. To specify the requirements, we first identify the
other parts of the information system that will interact with the database system. These include new
and existing users and applications, whose requirements are then collected and analyzed. Typically,
the following activities are part of this phase:
The major application areas and user groups that will use the database or whose work will be
affected by it are identified. Key individuals and commit-tees within each group are chosen to carry
out subsequent steps of requirements collection and specification.
Existing documentation concerning the applications is studied and analyzed. Other
documentation—policy manuals, forms, reports, and organization charts—is reviewed to determine
whether it has any influence on the requirements collection and specification process.

The current operating environment and planned use of the information is studied. This
includes analysis of the types of transactions and their frequencies as well as of the flow of
information within the system. Geographic characteristics regarding users, origin of transactions,
destination of reports, and so on are studied. The input and output data for the transactions are
specified.

Written responses to sets of questions are sometimes collected from the potential database
users or user groups. These questions involve the users’ priorities and the importance they place on
various applications. Key individuals may be interviewed to help in assessing the worth of
information and in setting up priorities.

Requirement analysis is carried out for the final users, or customers, of the database system by a
team of system analysts or requirement experts. The initial requirements are likely to be informal,
incomplete, inconsistent, and partially incorrect. Therefore, much work needs to be done to
transform these early requirements into a specification of the application that can be used by
developers and testers as the starting point for writing the implementation and test cases. Because
the requirements reflect the initial understanding of a system that does not yet exist, they will
inevitably change. Therefore, it is important to use techniques that help customers converge
quickly on the implementation requirements.

There is evidence that customer participation in the development process increases customer
satisfaction with the delivered system. For this reason, many practitioners use meetings and
workshops involving all stakeholders. One such methodology of refining initial system
requirements is called Joint Application Design (JAD). More recently, techniques have been
developed, such as Contextual Design, which involve the designers becoming immersed in the
workplace in which the application is to be used. To help customer representatives better
understand the proposed system, it is common to walk through workflow or transaction scenarios
or to create a mock-up rapid prototype of the application.
The preceding modes help structure and refine requirements but leave them still in an informal
state. To transform requirements into a better-structured representa-tion, requirements
specification techniques are used. These include object oriented analysis (OOA), data flow
diagrams (DFDs), and the refinement of appli-cation goals. These methods use diagramming
techniques for organizing and presenting information-processing requirements. Additional
documentation in the form of text, tables, charts, and decision requirements usually accompanies
the dia-grams. There are techniques that produce a formal specification that can be checked
mathematically for consistency and what-if symbolic analyses. These methods may become
standard in the future for those parts of information systems that serve mission-critical functions
and which therefore must work as planned. The model-based formal specification methods, of
which the Z-notation and methodology is a prominent example, can be thought of as extensions of
the ER model and are there-fore the most applicable to information system design.
Some computer-aided techniques—called Upper CASE tools—have been proposed to help check
the consistency and completeness of specifications, which are usually stored in a single repository
and can be displayed and updated as the design progresses. Other tools are used to trace the links
between requirements and other design entities, such as code modules and test cases.
Such traceability databases are especially important in conjunction with enforced change-
management procedures for systems where the requirements change frequently. They are also used
in contractual projects where the development organization must provide documentary evidence to
the customer that all the requirements have been implemented.

The requirements collection and analysis phase can be quite time-consuming, but it is crucial to the
success of the information system. Correcting a requirements error is more expensive than
correcting an error made during implementation because the effects of a requirements error are
usually pervasive, and much more down-stream work has to be reimplemented as a result. Not
correcting a significant error means that the system will not satisfy the customer and may not even
be used at all. Requirements gathering and analysis is the subject of entire books.
When are Fact-Finding Techniques Used?
Many situations arise for fact-finding during the database system development life cycle. However,
fact-finding is particularly vital to the early stages of the life cycle, which includes database
planning, system definition, and requirements gathering, and analysis stages. It is during these
early stages where the database developer captures the necessary facts essential to build the
required database. Fact-finding is also used in the case of database design and the later stages of
the lifecycle but to a lesser extent. It is to be noted that it is important to make a rough estimation
of how much time and effort is required to be spent on fact-finding for a database project.

What Facts Collect?

Throughout the database system development life cycle, the database developer needs to confine
the facts about the current and future systems. It is also true for the data captured and the
citations produced at each stage. For example, problems come across during database design may
necessitate additional data capture on the requirements for the new system.

Fact-Finding Techniques
A database developer commonly uses several fact-finding techniques during a single
database project. There are five widely used fact-finding techniques:

 Examining documentation
 Interviewing
 Observing the enterprise in action
 Research
 Questionnaires

Let us discuss in brief each of them:

1. Examining documentation can be helpful when you try to gain some insight as to how the
requirement for a database arose. You may also find that documentation can help to acquire
information on the part of the enterprise associated with the problem. If the problem relates to
the current system, there should have to be documents associated with that system. By
examining
 documents, forms, reports, and files associated with the current system, you can quickly gain
some thoughtful concepts out of the system.
2. Interviewing is the most frequently used, and usually the most useful, fact-finding procedure used.
We can interview to collect information from person face-to-face. There can be several objectives
for using interviewing, such as finding out facts, verifying those facts, clarifying these released
facts, generating enthusiasm, getting the end-user involved, identifying requirements, and
gathering ideas and opinions. However, using the interviewing practice must require proper
communication skills for dealing effectively with people who have different values, priorities,
opinions, motivations, and personalities.
3. Observing the enterprise in action: Observing the enterprise in action: Observation is one of
the most successful fact-finding techniques carried out for understanding a system. Using this
technique, it is achievable to either participate in or observe a person perform activities to learn
about the system.
4. Research: A useful fact-finding technique is to research the application or the problem that you are
dealing with and want to put within a database. Computer trade journals, reference books, and the
Internet are good sources of information that can make available the vast quantity of information
on how others have solved similar problems/issues plus whether or not any software packages exist
to resolve or even partially solve your current problem.
5. Questionnaires: Another fabulous fact-finding method is to conduct surveys through
questionnaires. Questionnaires are special-purpose documents that allow facts to be gathered from
a large number of people while upholding some control over their responses. When dealing with a
large number of listeners or audience, no other fact-finding technique can tabulate the same facts so
efficiently. There are two types of questions that can be asked in a questionnaire, namely free-
format and fixed-format. Free-format questions offer the respondent greater freedom inputting
answers. Fixed-format questions require specific responses from individuals, and for the given
question, the respondent must choose from the available answers.

Collecting Data

Collecting data is relatively easy, but turning raw information into something useful requires that
you know how to extract precisely what you need. In this module, intermediate to experienced
programmers interested in data analysis will learn techniques for working with data in a business
environment. You will learn how to look at data to discover what it contains, how to capture
those ideas in conceptual models, and then feed your understanding back into the organization
through business plans, metrics dashboards, and other applications. Along the way, you will
experiment with concepts through hands-on exercises at various points in the moule.

1. Use graphics to describe data with one, two, or dozens of variables

2. Develop conceptual models using back-of-the-envelope calculations, as well as scaling
and probability arguments
3. Mine data with computationally intensive methods such as simulation and clustering
4. Make your conclusions understandable through reports, dashboards, and other
metrics programs
5. Understand financial calculations, including the time value of money
6. Use dimensionality reduction techniques or predictive analytics to conquer challenging
data analysis situations
7. Become familiar with different open source programming environments for data analysis

DBLC Requirements Analysis

As mentioned earlier in this course, Requirements Analysis is the most important and
most labor-intensive stage in the DBLC. It is critical for the designer to approach
Requirements
 Analysis armed with a plan for each task in the process.
Experience is the great teacher when it comes to assessing informational needs, but there is
no substitute for preparation, specially for new designers. Most database designers begin
Requirements Analysis by examining the existing database(s) to establish a framework for
the remaining tasks. Analyzing how an organization stores data about its business objects[1],
and scrutinizing its perception of how it uses stored data (for example, gaining familiarity
with its business rules)[2] provides that framework.

Requirements Analysis

The goals of the requirements analysis are:

1. To determine the data requirements of the database in terms of primitive objects

2. To classify and describe the information about these objects
3. To identify and classify the relationships among the objects
4. To determine the types of transactions that will be executed on the database and
the interactions between the data and the transactions
5. To identify rules governing the integrity of the data

The modeler works with the end users of an organization to determine the data requirements of the
database. Information needed for the requirements analysis can be gathered in several ways:
Review of existing documents:Such documents include existing forms and reports, written
guidelines, job descriptions, and personal narratives. Paper documentation is a good way to
become familiar with the organization or activity you need to model.

Tips for Successful Requirements Collection

Following are some of the tips for making the requirements collection process successful:

● Never assume that you know the customer's requirements. What you usually
think,could be quite different to what the customer wants. Therefore, always verify with
the customer when you have an assumption or a doubt.
● Get the end-users involved from the start. Get their support for what you do. ●
At the initial levels, define the scope and get customer's agreement. This helps you to
successfully focus on scope of features.
● When you are in the process of collecting the requirements, make sure
that the requirements are realistic, specific and measurable.
● Focus on making the requirements document crystal clear. Requirement document is the
only way to get the client and the service provider to an agreement. Therefore, there
should not be any gray area in this document. If there are gray areas, consider this would
lead to potential business issues.
● Do not talk about the solution or the technology to the client until all the requirements
are gathered. You are not in a position to promise or indicate anything to the client until
 you are clear about the requirements.
● Before moving into any other project phases, get the requirements document
signed off by the client.
● If necessary, create a prototype to visually illustrate the requirements.
Finalizing the requirements of the system to be built forms the backbone for the ultimate success of the
project. It not only includes ascertaining the functions, but also the constraints of the system. The later part
is very important as the customer needs to be very clear about the services that are going to be offered by
the system. This will avoid any conflicts during the delivery or intermediate meetings with the client as the
client assumes that the system provides those functions which are actually constraints of the system.
When the requirements of the system are inaccurate, it may lead to the following problems:
1. Delivery schedules may be slipped.
2. Developed system may be rejected by the client leading to the loss of reputation and amount
spent on the project.
3. System developed may be unreliable.
4. Overall cost of the project may exceed the estimates.
There are different ways of finding the system requirements. Two of them are joint application development
and prototyping.

4. DATABASE DESIGN

What is Database

Design?

Database Design is a collection of processes that facilitate the designing, development,

implementation and maintenance of enterprise data management systems. Properly designed
database are easy to maintain, improves data consistency and are cost effective in terms of
disk storage space. The database designer decides how the data elements correlate and what
data must be stored.

The main objectives of database design in DBMS are to produce logical and physical
designs models of the proposed database system.

The logical model concentrates on the data requirements and the data to be stored independent
of physical considerations. It does not concern itself with how the data will be stored or where
it will be stored physically.

The physical data design model involves translating the logical DB design of the
database onto physical media using hardware resources and software systems such as
database management systems (DBMS).

In this Database design tutorial, you will learn-

● Why Database Design is Important?
● Database development life cycle
 ● Requirements analysis
● Database designing
● Implementation
● Types of Database Techniques

Why Database Design is Important?

It helps produce database systems
1. That meet the requirements of the users
2. Have high performance.
Database design process in DBMS is crucial for high performance database system.
Note, the genius of a database is in its design. Data operations using SQL is relatively
simple Database development life cycle

Requirements analysis

● Planning – This stages of database design concepts are concerned with planning of
entire Database Development Life Cycle. It takes into consideration the
Information Systems strategy of the organization.
● System definition – This stage defines the scope and boundaries of the
proposed database system.

Database designing

● Logical model – This stage is concerned with developing a database model based on
requirements. The entire design is on paper without any physical implementations or
specific DBMS considerations.
● Physical model – This stage implements the logical model of the database taking
into account the DBMS and physical implementation factors.

Implementation

 Data conversion and loading – this stage of relational databases design is

concerned with importing and converting data from the old system into the new
database.

 Testing
– this stage is concerned with the identification of errors in the newly
implemented system. It checks the database against requirement specifications.
The methodology is depicted as a bit by bit guide to the three main phases of database
design, namely: conceptual, logical, and physical design.

The primary aim of each phase is as follows:

 Conceptual database design - to build the conceptual representation of the

database, which has the identification of the important entities, relationships, and
attributes.

 Logical database design - to convert the conceptual representation to the logical

structure of the database, which includes designing the relations.
 Physical database design - to decide how the logical structure is to be physically
implemented (as base relations) in the target Database Management System
(DBMS).

Database Design
Database design is the process of creating a design that will support the enterprise's mission
statement and mission objectives for the required database system. Two main approaches to
the design of a database are followed. These are:

 bottom-up and
 top-down

The bottom-up approach starts at the fundamental level of attributes (i.e., properties of entities
and relationships), which through analysis of the associations between attributes, are clustered
into relations that signify types of entities and relationships between entities.

A more appropriate strategy for the design of complex databases is to use the top-down
approach, which starts with the development of data models that holds few high-level entities
and relationships and then apply consecutive top-down refinements to identify lower-level
entities, relationships, and the associated attributes. The top-down approach can be understood
better using the concepts of the Entity-Relationship (ER) model, beginning with the identification
of entities and relationships between the entities, which are of interest to the organization.

Introduction to the Database Design Methodology

A structured approach that uses procedures, techniques, tools, and documentation help to
support and make possible the process of design is called Design Methodology.

A design methodology encapsulates various phases, each containing some stages, which guide
the designer in the techniques suitable at each stage of the project. A design methodology also
helps the designer to plan, manage, control, and evaluate database development and managing
projects. Furthermore, it is a planned approach for analyzing and modeling a group of
requirements for a database in a standardized and ordered manner.

This stage is made up of three phases:

 Conceptual
 Logical and
 Physical database design
Conceptual Database Design

In this design methodology, the process of constructing a model of the data is used in an
enterprise, independent of all physical considerations. The conceptual database design phase starts
with the formation of a conceptual data model of the enterprise that is entirely independent of
implementation details such as the target DBMS, use of application programs, programming
languages used, hardware platform, performance issues, or any other physical deliberations.

Critical Success Factors in Database Design

The following planning strategies are often critical to the success of database design:

 Deal with task interactively with the users as much as possible.

 Follow a prearranged methodology throughout the data modeling process.
 Make use of a data-driven approach.
 Incorporate structural and integrity considerations into the data models.
 Combine conceptualization, normalization, and transaction validation methods into the
data modeling methodology.
 Use figures for representing as much of the data models as possible.
 Use a Database Design Language (DBDL) to represent additional data semantics
that cannot usually be represented in a diagram.
 Build a data dictionary to add-on the data model diagrams and the DBDL.
 Be willing to repeat steps.

These factors are constructed into the methodology that is presented for database design.

What are the steps for Conceptual Database Design?

Conceptual database design steps are:

 Build a conceptual data model

 Recognize entity types
 Recognize the relationship types
 Identify and connect attributes with entity or relationship types
 Determine attribute domains
 Determine candidate, primary, and alternate key attributes
 Consider the use of improved modeling concepts (optional step)
 Check model for redundancy
 Validate the conceptual model against user transactions
 Review the conceptual data model with user

Building a Conceptual Data Model

The first step in conceptual database design is to build one (or more) conceptual data replica of
the data requirements of the enterprise. A conceptual data model comprises these following
elements:

 entity types
 types of relationship
  attributes and the various attribute domains
 primary keys and alternate keys
 integrity constraints

The conceptual data model is maintained by documentation, including ER diagrams and a

data dictionary, which is produced throughout the development of the model.

you have already come across the basics of what methodologies are and their stages. You have
gathered the basic concept of what conceptual methodology is and how it works within the
main stages of the database system development life cycle.

Details on Logical Methodology

A local logical data model is used to characterize the data requirements of one or more but not all
user views of a database, and a universal logical data model represents the data requirements for
all user views. The final step of the logical database design phase is to reflect on how well the
model can support possible future developments for the database system.

Logical Database Design Methodology for the Relational Model

The objective of logical database design methodology is to interpret the conceptual data model
into a logical data model and then authorize this model to check whether it is structurally correct
and able to support the required transactions or not.

In this step of the database development life cycle, the main purpose is to translate the
conceptual data model created in conceptual methodology (of the previous chapter) into a logical
data model of the data requirements of the enterprise. This objective can be achieved by
following the activities given below:

 Obtain the relations for the logical data model

 Authorize those relations using normalization
 Validate those relations against user transactions
 Check integrity control and its limitation
 Evaluate the logical data model with user
 Combine logical data models into the global model (This step is an optional one)
 Check for future growth and development

The structure of the relational schema is authorized using normalization. It then makes sure to
ensure that the relations are capable of supporting the transactions given in the users' requirements
specification. You can then check those all-important integrity constraints that are characterized by
the logical data model. At this stage, the logical data model is authorized by the users to ensure
that they consider the model to be a true demonstration of the data requirements for the enterprise.

Derive Relations for Logical Data Model

The relationship that an entity has with other entities is characterized using the primary key or
foreign key's concept. In deciding where to post the foreign key attribute(s), firstly, you must
have to identify the 'parent' and 'child' entities that are involved in that relationship. The parent
entity refers to the entity that posts a copy of its primary key into the relation that represents the
child entity to act as the foreign key. You can describe how relations are obtained for the
following
structures that may occur in a conceptual data model:

 strong entity types

 weak entity types
 one-to-many (1:*) binary relationship types
 one-to-one (1:1) binary relationship types
 one-to-one (1:1) recursive relationship types
 superclass/subclass relationship types
 many-to-many (*:*) binary relationship types
 complex relationship types
 multi-valued attributes

Validate Relations Using Normalization

In the previous step, you have derived a set of relations from signifying the conceptual data model
created in the earlier step. Now, in the next step, you have to validate the groupings of attributes
in each relation using the rules of normalization. The purpose of normalization is to ensure that
the position of relations has a minimal and yet sufficient number of attributes necessary to support
the data requirements of the enterprise.

Validate Relations against User Transactions

The primary purpose of this step is to validate the logical data model to make certain that the
model supports the required transactions, as the users' requirements specification. By using the
relations, the primary key / foreign key links within the relations, the ER diagram, and the data
dictionary, you can attempt to perform the operations manually. If you can resolve all transactions
in this way, you can validate the logical data model against the transactions.

This physical methodology is the third and final phase of the database design methodology. Here,
the designer must decide how to translate the logical database design (i.e., the entities, attributes,
relationships, and constraints) into a physical database design, which can ultimately be
implemented using the target DBMS. As the various parts of physical database design are highly
reliant on the target DBMS, there may be more than one method of implementing any given
portion of the database. Consequently, to do this work appropriately, the designers must be fully
aware of the functionality of the target DBMS. They must recognize the advantages and
disadvantages of each alternative approach for a particular accomplishment. For some systems,
the designer may also need to select a suitable storage space/strategy that can take account of
intended database usage.

What is Physical Database Design?

It is the process of making a description of the execution of the database on secondary

storage, which describes the base relations, file organizations as well as indexes used to gain
efficient access to the data and any associated integrity constraints and security measures.

Comparison of Logical and Physical Database Design

In designing and presenting a database design methodology, you have to divide the design
process into three main stages or steps, also known as the Database development life cycle. These
steps or stages are:
  Conceptual
 Logical and
 Physical database design

The phase before the physical design is the logical database design, which is largely independent
of implementation details, such as the specific functionality of the target DBMS and application
programs, but is reliant on the target data model. The outcome of this process is a logical data
model that consists of an ER/relation diagram, relational schema, and supporting documents that
depict this model, such as a data dictionary.

Logical database designs are concerned with the "what," and in contrast, physical database
design is concerned with the "how." It requires diverse skills that are often found in different
people. In particular, the physical database designer must know how the computer system hosts
the DBMS and how it operates and must be fully conscious of the working of the target DBMS.

Steps Required for Implementing Physical Methodology

The steps of the physical database design methodology are as follows:

 Transform the logical data model for target DBMS

o Design base relations
o Design representation of derived data
o Design general constraints

 Design file organizations and indexes

o Analyze transactions
o Choose file organizations
o Choose indexes
o Estimate disk space requirements
o Design user views
o Design security mechanisms
o Consider the introduction of controlled redundancy
o Monitor and tune the operational system

Common Characteristics of a Physical Data Model

 It typically illustrates data requirements for a single project or application. Sometimes

even a part of an application
 May be incorporated into other physical data models by means of a repository of
shared entities
 It typically includes 10-1000 tables; although these numbers are highly variable,
depending on the scope of the data model
 It has the relationships between tables that address cardinality and nullability
(optionality) of the relationships
 Designed and developed to be reliant on a specific version of a DBMS, storage location
of data or technology
 Database columns will have data types with accurate precisions and lengths assigned
to them. Columns will have nullability (optional) assigned
 Tables and columns will have specific definitions
 5. What is ER Modeling?

An Entity–relationship model (ER model) describes the structure of a database with the help of
a diagram, which is known as Entity Relationship Diagram (ER Diagram). An ER model is a
design or blueprint of a database that can later be implemented as a database. The main
components of E-R model are: entity set and relationship set.

What is an Entity Relationship Diagram (ER Diagram)?

An ER diagram shows the relationship among entity sets. An entity set is a group of similar
entities and these entities can have attributes. In terms of DBMS, an entity is a table or attribute of
a table in database, so by showing relationship among tables and their attributes, ER diagram
shows the complete logical structure of a database. Lets have a look at a simple ER diagram to
understand this concept.

ENTITY
An entity is an object that exists and is distinguishable from other objects.
Example: specific person, company, event, plant
An entity set is a set of entities of the same type that share the same properties.
Example: set of all persons, companies, trees, holidays
E-R DIAGRAM (ENTITY RELATIONSHIP DIAGRAM)

ER-Diagram is a visual representation of data that describes how data is related to each other.

 E-R Model was proposed by Dr. Peter Chen

 E-R model is graphical in nature, thus making it easy to analyze and Observe
relationship between data elements
 Most DBMS are based upon E-R model
 A simple ER Diagram:

In the following diagram we have two entities Student and College and their relationship. The
relationship between Student and College is many to one as a college can have many students
however a student cannot study in multiple colleges at the same time. Student entity has
attributes such as Stu_Id, Stu_Name & Stu_Addr and College entity has attributes such as
Col_ID & Col_Name.

Here are the geometric shapes and their meaning in an E-R Diagram. We will discuss these
terms in detail in the next section(Components of a ER Diagram) of this guide so don’t worry
too much about these terms now, just go through them once.

Rectangle: Represents Entity sets.

Ellipses: Attributes
Diamonds: Relationship Set
Lines: They link attributes to Entity Sets and Entity sets to Relationship Set
Double Ellipses: Multivalued
Attributes Dashed Ellipses: Derived
Attributes Double Rectangles: Weak
Entity Sets
Double Lines: Total participation of an entity in a relationship set
 Components of a ER Diagram

As shown in the above diagram, an ER diagram has three main components:

1. Entity
2. Attribute
3. Relationship

1. Entity

An entity is an object or component of data. An entity is represented as rectangle in an ER

diagram. For example: In the following ER diagram we have two entities Student and College and
these two entities have many to one relationship as many students study in a single college. We
will read more about relationships later, for now focus on entities.
Weak Entity:
An entity that cannot be uniquely identified by its own attributes and relies on the relationship
with other entity is called weak entity. The weak entity is represented by a double rectangle. For
example – a bank account cannot be uniquely identified without knowing the bank to which the
account belongs, so bank account is a weak entity.

2. Attribute

An attribute describes the property of an entity. An attribute is represented as Oval in an

ER diagram. There are four types of attributes:

1. Key attribute
2. Composite attribute
3. Multivalued attribute
4. Derived attribute

1. Key attribute:
A key attribute can uniquely identify an entity from an entity set. For example, student roll
number can uniquely identify a student from a set of students. Key attribute is represented by oval
same as other attributes however the text of key attribute is underlined.

2. Composite attribute:

An attribute that is a combination of other attributes is known as composite attribute. For

example, In student entity, the student address is a composite attribute as an address is composed
of other attributes such as pin code, state, country.

3. Multivalued attribute:

An attribute that can hold multiple values is known as multivalued attribute. It is represented
with double ovals in an ER Diagram. For example – A person can have more than one
phone numbers so the phone number attribute is multivalued.

4. Derived attribute:

A derived attribute is one whose value is dynamic and derived from another attribute. It is
represented by dashed oval in an ER Diagram. For example – Person age is a derived attribute as
it changes over time and can be derived from another attribute (Date of birth).
E-R diagram with multivalued and derived attributes:

3. Relationship

A relationship is represented by diamond shape in ER diagram, it shows the relationship

among entities. There are four types of relationships:
1. One to One
2. One to Many
3. Many to One
4. Many to Many

1. One to One Relationship

When a single instance of an entity is associated with a single instance of another entity then it is
called one to one relationship. For example, a person has only one passport and a passport is
given to one person.

2. One to Many Relationship

When a single instance of an entity is associated with more than one instances of another entity
then it is called one to many relationship. For example – a customer can place many orders but
a order cannot be placed by many customers.

3. Many to One Relationship

When more than one instances of an entity is associated with a single instance of another
entity then it is called many to one relationship. For example – many students can study in a
single college but a student cannot study in many colleges at the same time.

4. Many to Many Relationship

When more than one instances of an entity is associated with more than one instances of another
entity then it is called many to many relationship. For example, a can be assigned to many
projects and a project can be assigned to many students.

Total Participation of an Entity set

Total participation of an entity set represents that each entity in entity set must have at least one
relationship in a relationship set. It is also called mandatory participation. For example: In
the following diagram each college must have at-least one associated Student. Total
participation is represented using a double line between the entity set and relationship set.

Partial participation of an Entity Set

Partial participation of an entity set represents that each entity in the entity set may or may
not participate in the relationship instance in that relationship set. It is also called as optional
participation
Partial participation is represented using a single line between the entity set and relationship set.

Example: Consider an example of an IT company. There are many employees working for the
company. Let’s take the example of relationship between employee and role software engineer.
Every software engineer is an employee but not every employee is software engineer as there
are employees for other roles as well, such as housekeeping, managers, CEO etc. so we can say
that participation of employee entity set to the software engineer relationship is partial.

6. Enhanced Entity Relationship (EER) Model

EER is a high-level data model that incorporates the extensions to the original ER model.
Enhanced ERD are high level models that represent the requirements and complexities of complex
database.
In addition to ER model concepts EE-R includes −

 Subclasses and Super classes.

 Specialization and Generalization.
 Category or union type.
 Aggregation.
These concepts are used to create EE-R diagrams.
Subclasses and Super class
Super class is an entity that can be divided into further
subtype. For example − consider Shape super class.

Super class shape has sub groups: Triangle, Square and Circle.
Sub classes are the group of entities with some unique attributes. Sub class inherits the properties
and attributes from super class.
Specialization and Generalization
Generalization is a process of generalizing an entity which contains generalized attributes or
properties of generalized entities.
It is a Bottom up process i.e. consider we have 3 sub entities Car, Truck and Motorcycle. Now
these three entities can be generalized into one super class named as Vehicle.
Specialization is a process of identifying subsets of an entity that share some different
characteristic. It is a top down approach in which one entity is broken down into low level entity.
In above example Vehicle entity can be a Car, Truck or Motorcycle.
Generalization Example

Lets say we have two entities Student and Teacher.

Attributes of Entity Student are: Name, Address & Grade
Attributes of Entity Teacher are: Name, Address & Salary

The ER diagram before generalization looks like this:

These two entities have two common attributes: Name and Address, we can make a
generalized entity with these common attributes. Lets have a look at the ER model after
generalization.
The ER diagram after generalization:
We have created a new generalized entity Person and this entity has the common attributes of
both the entities. As you can see in the following ER diagram that after the generalization process
the entities Student and Teacher only has the specialized attributes Grade and Salary respectively
and their common attributes (Name & Address) are now associated with a new entity Person
which is in the relationship with both the entities (Student & Teacher).

Note:
1. Generalization uses bottom-up approach where two or more lower level entities
combine together to form a higher level new entity.
2. The new generalized entity can further combine together with lower level entity to create
a further higher level generalized entity.

DBMS Specialization

Specialization is a process in which an entity is divided into sub-entities. You can think of it as
a reverse process of generalization, in generalization two entities combine together to form a
new higher level entity. Specialization is a top-down process.

The idea behind Specialization is to find the subsets of entities that have few distinguish
attributes. For example – Consider an entity employee which can be further classified as sub-
entities Technician, Engineer & Accountant because these sub entities have some distinguish
attributes.
 Specialization Example

In the above diagram, we can see that we have a higher level entity ―Employee‖ which we have
divided in sub entities ―Technician‖, ―Engineer‖ & ―Accountant‖. All of these are just an
employee of a company, however their role is completely different and they have few different
attributes. Just for the example, I have shown that Technician handles service requests, Engineer
works on a project and Accountant handles the credit & debit details. All of these three employee
types have few attributes common such as name & salary which we had left associated with the
parent entity
―Employee‖ as shown in the above diagram.

Category or Union
Relationship of one super or sub class with more than one super class.

Owner is the subset of two super class: Vehicle and House.

Aggregation
Represents relationship between a whole object and its component.
Consider a ternary relationship Works_On between Employee, Branch and Manager. Now the best
way to model this situation is to use aggregation, So, the relationship-set, Works_On is a higher
level entity-set. Such an entity-set is treated in the same manner as any other entity-set. We can
create a binary relationship, Manager, between Works_On and Manager to represent who manages
what tasks.
Aggregation is a process in which a single entity alone is not able to make sense in a relationship
so the relationship of two entities acts as one entity. I know it sounds confusing but don’t worry
the example we will take, will clear all the doubts.

Aggregration Example
In real world, we know that a manager not only manages the employee working under them but he
has to manage the project as well. In such scenario if entity ―Manager‖ makes a ―manages‖
relationship with either ―Employee‖ or ―Project‖ entity alone then it will not make any sense
because he has to manage both. In these cases the relationship of two entities acts as one entity. In
our example, the relationship ―Works-On‖ between ―Employee‖ & ―Project‖ acts as one entity that
has a relationship ―Manages‖ with the entity ―Manager‖.

Advantages of EER Models

 It is quite simple to develop and maintain. In addition to this, it is easy to understand

and interpret as well, technically speaking.
 Everything that is visually represented is easier to understand and maintain, and the
same goes for EER models.
 It has been an efficient tool for database designers. It serves as a communication tool
and helps display the relationship between entities.
 You can always convert the EER model into a table. Thus, it can easily be integrated into
a relational model.

Disadvantages/Limitations of EER Diagrams

 The EER diagrams have many constraints and come up with limited features.
 The Pareto Chart cannot be used for all the issues.
 Faults in the scoring of data can happen, plus also there could be an error in the application.
 Calculated on past data and therefore, cannot predict the future.

7.UML Class Diagram

Unified Modeling Language (UML) | Class
Diagrams What is UML?
It is the general-purpose modeling language used to visualize the system. It is a graphical
language that is standard to the software industry for specifying, visualizing, constructing, and
documenting the artifacts of the software systems, as well as for business modeling.
Benefits of UML:
 Simplifies complex software design, can also implement OOPs like a concept that is widely
used.
 It reduces thousands of words of explanation in a few graphical diagrams that may reduce
time consumption to understand.
 It makes communication more clear and more real.
 It helps to acquire the entire system in a view.
 It becomes very much easy for the software programmer to implement the actual demand
once they have a clear picture of the problem.

Types of UML: The UML diagrams are divided into two parts: Structural UML diagrams and
Behavioral UML diagrams which are listed below:
1. Structural UML diagrams
 Class diagram
 Package diagram
 Object diagram
 Component diagram
 Composite structure diagram
 Deployment diagram
2. Behavioral UML diagrams
 Activity diagram
 Sequence diagram
 Use case diagram
 State diagram
 Communication diagram
 Interaction overview diagram
 Timing diagram

A class consists of its objects, and also it may inherit from other classes. A class diagram is used to
visualize, describe, document various different aspects of the system, and also construct executable
software code.

It shows the attributes, classes, functions, and relationships to give an overview of the software
system. It constitutes class names, attributes, and functions in a separate compartment that helps in
software development. Since it is a collection of classes, interfaces, associations, collaborations,
and constraints, it is termed as a structural diagram.

Purpose of Class Diagrams

The main purpose of class diagrams is to build a static view of an application. It is the only
diagram that is widely used for construction, and it can be mapped with object-oriented languages.
It is one of the most popular UML diagrams. Following are the purpose of class diagrams given
below:

1. It analyses and designs a static view of an application.

2. It describes the major responsibilities of a system.
3. It is a base for component and deployment diagrams.
4. It incorporates forward and reverse engineering.

Benefits of Class Diagrams

1. It can represent the object model for complex systems.
2. It reduces the maintenance time by providing an overview of how an application is
structured before coding.
3. It provides a general schematic of an application for better understanding.
4. It represents a detailed chart by highlighting the desired code, which is to be programmed.
5. It is helpful for the stakeholders and the developers.
 Vital components of a Class Diagram

The class diagram is made up of three sections:

o Upper Section: The upper section encompasses the name of the class. A class is a
representation of similar objects that shares the same relationships, attributes, operations,
and semantics. Some of the following rules that should be taken into account while
representing a class are given below:
a.Capitalize the initial letter of the class name.
b. Place the class name in the center of the upper section.
c. A class name must be written in bold format.
d. The name of the abstract class should be written in italics format.
o Middle Section: The middle section constitutes the attributes, which describe the quality of
the class. The attributes have the following characteristics:
. The attributes are written along with its visibility factors, which are public (+), private (-),
protected (#), and package (~).
a. The accessibility of an attribute class is illustrated by the visibility factors.
b. A meaningful name should be assigned to the attribute, which will explain its usage
inside the class.
o Lower Section: The lower section contain methods or operations. The methods are
represented in the form of a list, where each method is written in a single line. It
demonstrates how a class interacts with data.

Relationships
In UML, relationships are of three types:

o Dependency: A dependency is a semantic relationship between two or more classes where

a change in one class cause changes in another class. It forms a weaker relationship.
In the following example, Student_Name is dependent on the Student_Id.

o Generalization: A generalization is a relationship between a parent class (superclass) and a

child class (subclass). In this, the child class is inherited from the parent class.
For example, The Current Account, Saving Account, and Credit Account are the
generalized form of Bank Account.

o Association: It describes a static or physical connection between two or more objects. It

depicts how many objects are there in the relationship.
For example, a department is associated with the college.

Multiplicity: It defines a specific range of allowable instances of attributes. In case if a range is

not specified, one is considered as a default multiplicity.

For example, multiple patients are admitted to one hospital.

Aggregation: An aggregation is a subset of association, which represents has a relationship. It is
more specific then association. It defines a part-whole or part-of relationship. In this kind of
relationship, the child class can exist independently of its parent class.

The company encompasses a number of employees, and even if one employee resigns, the
company still exists.

Composition: The composition is a subset of aggregation. It portrays the dependency between the
parent and its child, which means if one part is deleted, then the other part also gets discarded. It
represents a whole-part relationship.

A contact book consists of multiple contacts, and if you delete the contact book, all the contacts
will be lost.

Abstract Classes

In the abstract class, no objects can be a direct entity of the abstract class. The abstract class can
neither be declared nor be instantiated. It is used to find the functionalities across the classes. The
notation of the abstract class is similar to that of class; the only difference is that the name of the
class is written in italics. Since it does not involve any implementation for a given function, it is
best to use the abstract class with multiple objects.

Let us assume that we have an abstract class named displacement with a method declared inside it,
and that method will be called as a drive (). Now, this abstract class method can be implemented
by any object, for example, car, bike, scooter, cycle, etc.
 How to draw a Class Diagram?

The class diagram is used most widely to construct software applications. It not only represents a
static view of the system but also all the major aspects of an application. A collection of class
diagrams as a whole represents a system.

Some key points that are needed to keep in mind while drawing a class diagram are given below:

1. To describe a complete aspect of the system, it is suggested to give a meaningful name

to the class diagram.
2. The objects and their relationships should be acknowledged in advance.
3. The attributes and methods (responsibilities) of each class must be known.
4. A minimum number of desired properties should be specified as more number of
the unwanted property will lead to a complex diagram.
5. Notes can be used as and when required by the developer to describe the aspects of
a diagram.
6. The diagrams should be redrawn and reworked as many times to make it correct before
producing its final version.

Class Diagram Example

A class diagram describing the sales order system is given below.

 Usage of Class diagrams

The class diagram is used to represent a static view of the system. It plays an essential role in the
establishment of the component and deployment diagrams. It helps to construct an executable code
to perform forward and backward engineering for any system, or we can say it is mainly used for
construction. It represents the mapping with object-oriented languages that are C++, Java, etc.
Class diagrams can be used for the following purposes:

1. To describe the static view of a system.

2. To show the collaboration among every instance in the static view.
3. To describe the functionalities performed by the system.
4. To construct the software application using object-oriented languages.

UML Object Diagram

Object diagrams are dependent on the class diagram as they are derived from the class diagram. It
represents an instance of a class diagram. The objects help in portraying a static view of an object-
oriented system at a specific instant.

Both the object and class diagram are similar to some extent; the only difference is that the class
diagram provides an abstract view of a system. It helps in visualizing a particular functionality of a
system.
 Notation of an Object Diagram

Purpose of Object Diagram

The object diagram holds the same purpose as that of a class diagram. The class diagram provides
an abstract view which comprises of classes and their relationships, whereas the object diagram
represents an instance at a particular point of time.

The object diagram is actually similar to the concrete (actual) system behavior. The main purpose
is to depict a static view of a system.

Following are the purposes enlisted below:

o It is used to perform forward and reverse engineering.

o It is used to understand object behavior and their relationships practically.
o It is used to get a static view of a system.
o It is used to represent an instance of a system.

Example of Object Diagram

How to draw an Object Diagram?

1. All the objects present in the system should be examined before start drawing the
object diagram.
2. Before creating the object diagram, the relation between the objects must be acknowledged.
3. The association relationship among the entities must be cleared already.
4. To represent the functionality of an object, a proper meaningful name should be assigned.
5. The objects are to be examined to understand its functionality.

Applications of Object diagrams

The following are the application areas where the object diagrams can be used.

1. To build a prototype of a system.

2. To model complex data structures.
3. To perceive the system from a practical perspective.
4. Reverse engineering.

Class vs. Object diagram

Serial Class Diagram Object Diagram
No.

1. It depicts the static view of a system. It portrays the real-time behavior of a

system.

2. Dynamic changes are not included in the class Dynamic changes are captured in the
diagram. object diagram.

3. The data values and attributes of an instance are It incorporates data values and
not involved here. attributes of an entity.

4. The object behavior is manipulated in the class Objects are the instances of a class.
diagram.