INFORMATION

MODELLING
E R DIAGRAMS
 WHERE CAN WE AGREE?
 Heterogeneity hinders the development of enterprise systems (Including
Distributed One)
 There will not be consensus on
 Hardware
 Operating systems
 Network protocols
 Programming languages
 We can agree at an higher level
 Platform Independent Analysis & Specification of Problem
Model (Miniature shape of real time system)
 CHARACTERISTICS OF A MODEL
 Abstraction
 Focus/Scope
 Expressiveness vs. Analytic Power vs. Complexity
 Intuitive vs. Non-intuitive Representation
 Accuracy
 Preserve all the properties of Actual System
 MODELS
 Software engineering models and methods impose structure on
software engineering with the goal of making that activity
systematic, repeatable, and ultimately more success-oriented.
 Using models provides an approach to problem solving, a
notation, and procedures for model construction and analysis.
 Methods provide an approach to the systematic specification,
design, construction, test, and verification of the end-item software
and associated work products.
 Software engineering models and methods vary widely in scope
—from addressing a single software life cycle phase to covering
the complete software life cycle.
 Modeling
Modeling of software is becoming a pervasive
technique to help software engineers understand,
engineer, and communicate aspects of the software
to appropriate stakeholders.
While there are many modeling languages,
notations, techniques, and tools in the literature
and in practice, there are unifying general
concepts that apply in some form to them all.
 Properties of models are those distinguishing features of a
particular model used to characterize its
 Completeness: the degree to which all requirements have
been implemented and verified within the model.
 Consistency: the degree to which the model contains no
conflicting requirements, assertions, constraints,
functions, or component descriptions.
 Correctness: the degree to which the model satisfies its
requirements and design specifications and is free of
defects.
 within the chosen modeling notation and tooling used.
 WHY DO WE MODEL

 Provide structure for problem solving

 Experiment to explore multiple solutions
 Furnish abstractions to manage complexity
 Reduce time-to-market for business problem solutions
 Decrease development costs
 Manage the risk of mistakes
 WHY DO WE MODEL
PURPOSE OF A MODEL
 Models are representations that can aid in defining,

analyzing, and communicating a set of concepts.

 System models are specifically developed to support

analysis, specification, design, verification,
and validation of a system.
 As well as to communicate certain information.
 One of the first principles of modeling is to clearly

define the purpose of the model.

 Some of the purposes that models can serve throughout the system life
cycle are:

 Characterizing an existing system: 

 Many existing systems are poorly documented and modeling the system
can provide a concise way to capture the existing system design.
 This information can then be used to facilitate system maintenance or to

assess the system with the goal of improving it.

 This is analogous to creating an architectural model of an old building

with overlays for electrical, plumbing, and structure

 Before proceeding to upgrade it to new standards to withstand
earthquakes.
 Mission and system concept formulation and evaluation:
 Models can be applied early in the system life cycle to synthesize

and evaluate alternative mission and system concepts.

 This includes clearly and unambiguously defining the system's
mission and the value it is expected to deliver to its beneficiaries.
 Models can be used to explore a trade-space by modeling alternative
system designs and assessing the impact of critical system
parameters such as weight, speed, accuracy, reliability, and cost on
the overall measures of merit.
 In addition to bounding the system design parameters,
 Models can also be used to validate that the
system requirements meet stakeholder needs before proceeding
with later life cycle activities such as synthesizing the detailed
system design.
 System design synthesis and requirements flow down: 
 Models can be used to support architecting system solutions,
as well as flow mission and system requirements down to
system components.
 Different models may be required to address different aspects
of the system design and respond to the broad range of system
requirements.
 This may include models that specify functional, interface,
performance, and physical requirements, as well as other non-
functional requirements such as
reliability, maintainability, safety, and security.
 WHY DO WE MODEL contd..

 Some of the purposes that models can serve throughout the system life cycle are:
 Support for system integration and verification: 
 Models can be used to support integration of the hardware and software components into a
system, as well as to support verification that the system satisfies its requirements.
 This often involves integrating lower level hardware and software design models with
system-level design models which verify that system requirements are satisfied.
 System integration and verification may also include replacing selected hardware and
design models with actual hardware and software products in order to incrementally verify
that system requirements are satisfied. This is referred to as hardware-in-the-loop
testing and software-in-the-loop testing.
 Models can also be used to define the test cases (glossary) and other aspects of the
test program to assist in test planning and execution.
 .
 Support for training: 
 Models can be used to simulate various aspects of the system
to help train users to interact with the system.
 Users may be operators, maintainers, or other stakeholders.
 Models may be a basis for developing a simulator of the
system with varying degrees of fidelity to represent user
interaction in different usage scenarios.

 Knowledge capture and system design evolution: 

 Models can provide an effective means for capturing knowledge
about the system and retaining it as part of organizational
knowledge.
 This knowledge, which can be reused and evolved, provides a basis
for supporting the evolution of the system, such as changing system
requirements in the face of emerging, relevant technologies, new
applications, and new customers.
 Models can also enable the capture of families of products
 Models are forms of description often adopted in
software development.
 They are abstractions used to represent and
communicate what is important
 Devoid of unnecessary detail
 And to help developers deal with the complexity of
the problem being investigated or the solution being
developed.
 INFORMATION MODELLING
 An information model in software engineering is a
representation of concepts and the relationships, constraints,
rules, and operations to specify data semantics for a chosen
domain of discourse.
 Typically it specifies relations between kinds of things, but

may also include relations with individual things.

 It can provide sharable, stable, and organized structure of
information requirements or knowledge for the domain
context.
 The term information model in general is used for models of
individual things, such as facilities, buildings, process plants,
etc. In those cases, the concept is specialised to facility
information model, building information model, plant
information model, etc. Such an information model is an
integration of a model of the facility with the data and
documents about the facility.
 Within the field of software engineering and data modeling,
an information model is usually an abstract, formal
representation of entity types that may include their properties,
relationships and the operations that can be performed on them.
 The entity types in the information model may
be kinds of real-world objects, such as devices in
a network, or occurrences, or they may
themselves be abstract, such as for the entities
used in a billing system. Typically, they are used
to model a constrained domain that can be
described by a closed set of entity types,
properties, relationships and operations.
 An information model provides formalism to the
description of a problem domain without constraining
how that description is mapped to an actual
implementation in software.
 There may be many mappings of the information
model. Such mappings are called data models,
irrespective of whether they are object models (e.g.
using UML), entity relationship models or XML
schemas.
 Data vs. Requirements Modelling
 Data modeling in software engineering is used in software application
development.
 To understand data modeling and how it contributes to software engineering, it's
best to take a step back and examine how data modeling fits into requirements
modeling.
 Requirements modeling
 In software engineering is part of analysis and design. It's the planning stage
of developing a software application.
 Requirements modeling focuses on the ''what'', not the ''how.'‘
 In other words, requirements modeling identifies what requirements the
application must meet in order to be successful.
 Requirements modeling includes many sub-stages,
one of them being data modeling.
 Generally speaking, requirements modeling will
begin with scenario-based modeling, which results in
creating a use case. A use case, simply put, is a
primary example of how the software application will
be used and what it is expected to do. Once a use case
exists, one of the stages that follow will be data
modeling.
 Objects, Attributes, Relationships
 Data modeling
 Also called information modeling, is the process of visually representing what data
the application or system will use and how it will flow.
 The resulting diagram or other visual representation is meant to be designed in a way
that is as easy to understand as possible.
 The fundamental elements that a data model needs to
include and describe are the data objects, more
frequently called ''entities''; the attributes of those objects
or entities; and the relationships between the objects or
entities.
 Entities, attributes, and relationships are reviewed in
greater detail in the example use case that follows.
 It's worth noting that several methods can be used to
create the diagrams in data modeling. The two most
widely used are UML (or unified modeling language) and
ERD (or entity-relationship diagrams).
 Conceptual, Logical, Physical Data Models
 Traditionally, data modeling is comprised of three stages: conceptual, logical, and
physical modeling. These stages begin at the most abstract, or general, representation
of the data (conceptual modeling). Then, they proceed systematically to the most
detailed representation using physical modeling.
 Conceptual modeling primarily identifies the entities (data objects) that the
application will deal with, and traditionally doesn't describe the attributes of those
entities.
 This stage is deliberately abstract, to avoid becoming ''bogged down in details.'' This
way it allows all of the stakeholders to participate at this stage, without requiring
them to have any specific technical knowledge.
 For example, the representatives of the company who have commissioned the
application (who are not necessarily technically minded) can contribute meaningfully
alongside the software engineers (who are necessarily technically minded) in
designing the application.
 Logical modeling uses the entities identified during the
conceptual modeling stage and then identifies the attributes
these entities should have, along with the relationships
between the entities.
 And finally, physical modeling is the most detailed stage of
data modeling. The previously defined entities, attributes, and
relationships are used to design the database structure,
including all of the necessary details (like the number of
tables, columns, and data types needed).
 Conceptual, Logical and Physical data models

 ER models and data models are typically drawn at up to three levels of

detail:
 Conceptual data model: The highest-level view containing the least
detail. Its value is showing overall scope of the model and portraying
the system architecture. For a system of smaller scope, it may not be
necessary to draw. Instead, start with the logical model.
 Logical data model: Contains more detail than a conceptual model.
More detailed operational and transactional entities are now defined.
The logical model is independent of the technology in which it will be
implemented.
 Physical data model: One or more physical model may be
developed from each logical model. The physical models must
show enough technology detail to produce and implement the
actual database.
 Note that similar detail and scope levels exist in other types of
diagrams, such as data flow diagrams, but that it contrasts with
software engineering’s three schema approach, which divides the
information a bit differently.
 Sometimes, engineers will branch out ER diagrams with
additional hierarchies to add necessary information levels for
database design. For example, they may add groupings by extend
up with superclasses
 Entity Relationship Diagram (ER Diagrams)
 What is an ER diagram?
 An Entity Relationship Diagram (ERD) is a visual representation of different
entities within a system and how they relate to each other.
 History of ER Diagrams
 Although data modeling has become a necessity around 1970’s there was no
standard way to model databases or business processes. Although many
solutions were proposed and discussed none were widely adopted.
 Peter Chen is credited with introducing the widely adopted ER model in his
paper “The Entity Relationship Model-Toward a Unified View of Data“. The
focus was on entities and relationships and he introduced a diagramming
representation for database design as well.
 His model was inspired by the data structure diagrams introduced by Charles
Bachman. One of the early forms of ER diagrams, Bachman diagrams are
named after him.
 What is the use of ER Diagrams?
 What are the uses of ER diagrams? Where are they
used? Although they can be used to model almost any
system they are primarily used in the following areas.
 ER Models in Database Design
 They are widely used to design relational databases.
The entities in the ER schema become tables,
attributes and converted the database schema. Since
they can be used to visualize database tables and their
relationships it’s commonly used for database
troubleshooting as well.
Components of the ER Diagram
 E R Diagram
 For example, the elements writer, novel, and a consumer may be described using ER diagrams the following way:
Entity Relationship Diagrams in Software Engineering
 Entity relationship diagrams are used in software engineering during the planning stages of the software
project.
 They help to identify different system elements and their relationships with each other. It is often used as
the basis for data flow diagrams or DFD’s as they are commonly known.
 For example, an inventory software used in a retail shop will have a database that monitors elements such
as purchases, item, item type, item source and item price. Rendering this information through an ER
diagram would be something like this:

 In the diagram, the information inside the oval shapes are attributes of a particular entity.
 Entity Relationship Diagram (ERD) Symbols and Notations
 There are three basic elements in an ER Diagram:
 Entity, attribute, relationship.
 There are more elements which are based on the main elements.
 They are weak entity, multi valued attribute, derived attribute, weak relationship, and
recursive relationship.
 Cardinality and Ordinality are two other notations used in ER diagrams to further
define relationships.
 Entity
 An entity can be a person, place, event, or object that is relevant to a given
system.
Elements in ER diagrams
 For example, a school system may include students, teachers, major courses,
 Primary and foreign keys are the most basic components
on which relational database theory is based.
subjects, fees, and other items.
 Primary keys enforce entity integrity by uniquely  Entities are represented in ER diagrams by a rectangle and named using singular
identifying entity instances. nouns.
 Primary or Candidate key: A key used to uniquely
identify an entity set.
 Weak Entity
 Foreign keys enforce referential integrity by completing  A weak entity is an entity that depends on the existence of another entity.
an association between two entities.  In more technical terms it can be defined as an entity that cannot be identified by
 Foreign key: Helps to identify relationships between
entities. its own attributes.
 The next step in building the basic data model to:  It uses a foreign key combined with its attributes to form the primary key.
 Identify and define the primary key attributes for  An entity like order item is a good example for this. The order item will be
each entity
 Validate primary keys and relationships meaningless without an order so it depends on the existence of the order.
 Migrate the primary keys to establish foreign keys
 Super key: A set of attributes that helps together define
an entity uniquely, within an entity set.

                                                           Weak Entity Example in ER diagrams

Symbols used in ER diagram
Elements in ER diagram
 Basic Elements in an ER Diagram
 WHAT IS ENTITY?
 A real-world thing either living or non-living that is easily recognizable and non recognizable.
 It is anything in the enterprise that is to be represented in our database.
 It may be a physical thing or simply a fact about the enterprise or an event that happens in the real world.
 An entity can be place, person, object, event or a concept, which stores data in the database.
 The characteristics of entities are must have an attribute, and a unique key.
 Every entity is made up of some ‘attributes’ which represent that entity
 Examples of entities:
 Person: Employee, Student, Patient
 Place: Store, Building
 Object: Machine, product, and Car
 Event: Sale, Registration, Renewal
 Concept: Account, Course
 Entity set:
 Student
 An entity set is a group of similar kind of entities.
 It may contain entities with attribute sharing similar values.
 Entities are represented by their properties, which also called attributes.
 All attributes have their separate values.
 For example, a student entity may have a name, age, class, as attributes.
 Example of Entities:
 A university may have some departments.
 All these departments employ various lecturers and offer several programs.
 Some courses make up each program.
 Students register in a particular program and enroll in various courses.
 A lecturer from the specific department takes each course, and each lecturer teaches a various group of students.
 Relationship
 Relationship is nothing but an association among two or more entities. E.g., Tom works in the Chemistry department.
 . Entities take part in relationships. We can often identify relationships with verbs or verb phrases.
 WHAT IS ENTITY?
 A real-world thing either living or non-living that is
easily recognizable and non recognizable.
 It is anything in the enterprise that is to be represented
in our database.
 It may be a physical thing or simply a fact about the
enterprise or an event that happens in the real world.
 An entity can be place, person, object, event or a
concept, which stores data in the database.
 The characteristics of entities are must have an
attribute, and a unique key.
 Every entity is made up of some ‘attributes’ which
represent that entity
 Examples of entities:
 Person: Employee, Student, Patient
 Place: Store, Building
 Object: Machine, product, and Car
 Event: Sale, Registration, Renewal
 Concept: Account, Course
 Entity set:
 Student
 An entity set is a group of similar kind of entities.
 It may contain entities with attribute sharing similar values.
 Entities are represented by their properties, which also called attributes.
 All attributes have their separate values.
 For example, a student entity may have a name, age, class, as attributes.

 Example of Entities:
 A university may have some departments.
 All these departments employ various lecturers and offer several
programs.
 Some courses make up each program.
 Students register in a particular program and enroll in various courses.
 A lecturer from the specific department takes each course, and each
lecturer teaches a various group of students.
 Relationship
 Relationship is nothing but an association among two
or more entities. E.g., Tom works in the Chemistry
department.
 . Entities take part in relationships. We can often
identify relationships with verbs or verb phrases.
 Basic Elements in an ER Diagram
 Weak Entities
 A weak entity is a type of entity which doesn’t have its key attribute.
 It can be identified uniquely by considering the primary key of another entity.
 For that, weak entity sets need to have total participation.

In above ER Diagram examples, “Trans No” is a discriminator within a

group of transactions in an ATM.
 STRONG ENTITY vs WEAK ENTITY

Strong Entity Set Weak Entity Set

It does not have enough attributes to build a primary
Strong entity set always has a primary key.
key.

It is represented by a rectangle symbol. It is represented by a double rectangle symbol.

It contains a Primary key represented by the underline It contains a Partial Key which is represented by a
symbol. dashed underline symbol.

The member of a strong entity set is called as The member of a weak entity set called as a
dominant entity set. subordinate entity set.

Primary Key is one of its attributes which helps to In a weak entity set, it is a combination of primary
identify its member. key and partial key of the strong entity set.

The relationship between one strong and a weak

In the ER diagram the relationship between two
entity set shown by using the double diamond
strong entity set shown by using a diamond symbol.
symbol.
 Basic Elements in an ER Diagram
 Attribute
 An attribute is a property, trait, or characteristic of an entity, relationship, or another attribute.
 For example, the attribute Inventory Item Name is an attribute of the entity Inventory Item.
 An entity can have as many attributes as necessary.
 Meanwhile, attributes can also have their own specific attributes.
 For example, the attribute “customer address” can have the attributes number, street, city, and state. These are
called composite attributes.
 Note that some top level ER diagrams do not show attributes for the sake of simplicity. In those that do, however,
attributes are represented by oval shapes.

Attributes in ER diagrams, Note that an attribute can have its own attributes ( composite attribute )
If an attribute has more than one value,
it is called multi-valued attribute
 Basic Elements In An ER Diagram
 Attributes
 It is a single-valued property of either an entity-type or a relationship-type.
 For example, a lecture might have attributes: time, date, duration, place, etc.
 An attribute in ER Diagram examples, is represented by an Ellipse.
Types of Attributes Description
Simple attributes can’t be divided any further. For
Simple attribute example, a student’s contact number. It is also
called an atomic value.

It is possible to break down composite attribute.

For example, a student’s full name may be further
Composite attribute
divided into first name, second name, and last
name.

This type of attribute does not include in the

physical database. However, their values are
derived from other attributes present in the
Derived attribute
database. For example, age should not be stored
directly. Instead, it should be derived from the
DOB of that employee.

Multivalued attributes can have more than one

Multivalued attribute values. For example, a student can have more
than one mobile number, email address, etc.
 Basic Elements in an ER Diagram
 Relationship
 A relationship describes how entities interact.
 For example, the entity “Carpenter” may be related to the entity “table” by the relationship “builds”
or “makes”.
 Relationships are represented by diamond shapes and are labeled using verbs.

Using Relationships in Entity Relationship Diagrams

 Recursive Relationship
 If the same entity participates more than once in a relationship it is known as
a recursive relationship.
 In the below example an employee can be a supervisor and be supervised, so
there is a recursive relationship.
 Cardinality

It further defines relationships between entities by placing the

relationship in the context of numbers.
In an email system, for example, one account can have
multiple contacts. The relationship, in this case, follows a
“one to many” model.
There are a number of notations used to present cardinality in
ER diagrams. Chen, UML, Crow’s foot, Bachman are some of
the popular notations. 
 Cardinality
 Defines the numerical attributes of the relationship between
two entities or entity sets.
 The three main cardinal relationships are one-to-one, one-to-
many, and many-many.
 A one-to-one example would be one student associated with
one mailing address.
 A one-to-many example (or many-to-one, depending on the
relationship direction): One student registers for multiple
courses, but all those courses have a single line back to that
one student.
 Many-to-many example: Students as a group are associated
with multiple faculty members, and faculty members in turn
are associated with multiple students.
Cardinality notations
 Cardinality views: 
Cardinality can be shown as look-across or
same-side, depending on where the symbols
are shown.
 Cardinality constraints:
The minimum or maximum numbers that
apply to a relationship
 Cardinality
 Defines the numerical attributes of the relationship between two entities or entity sets.

 Different types of cardinal relationships are:

One-to-One Relationships
One-to-Many Relationships
May to One Relationships
Many-to-Many Relationships
 Cardinality

2.One-to-many:
One entity from entity set X can be associated with multiple entities of entity set
Y, but an entity from entity set Y can be associated with at least one entity.
For example, one class is consisting of multiple students.
 MODALITY
 Modality can be interpreted as a Required Connection OR a Not Required Connection.
 This means if Modality is 0 then there doesn’t have to be a connection at all. If The value is 1 then we have that connection
 EXAMPLE:
 Think of a credit card company that has two tables:
 a table for the person who gets the card and a table for the card itself.
 A row from the cardholder table would have a relationship with a row in the card table because the cardholder
holds the card. (Fig. 1)

Fig 1 Here is an example of a one to one

relationship.

 If a cardholder can have only one card this would be a one to one relationship.
If the card holder can have multiple cards it would be a one to
many relationship: Here the previous example updated with a one
to many relationship.(Fig 2)
 In a one to one relationship we have a connection
from one row of the first table to one row of another
table. In a one to many relationship we have a
connection from one row of the first table to one or
multiple rows of the other table.
 In the card table we have a column called holder_id.
This has a connection to the cardholder table because
a credit card is owned by somebody who will use it.
 Now, if the modality is 0 or more, than we can have
a row without a holder_id value. If the modality is 1
or more, than we must have a value in the holder_id
column.
 Modality of 0 or more = A card is not required to be held.
This means that the table not only holds active cards, but
it may hold cards that are not currently held by anybody.
This is called a null able column because it accepts an
empty field.
 Modality of 1 or more = A card is required to be held. This
means that a card with no owner would not be able to be
put in this table. This is said to be a not null column
because it does not accept nulls.
 We can also draw modality in our crow’s foot notation. If
the modality is zero or more, we put a little circle right
beside the cardinality. If the modality is one or more, we
put a vertical line next to the cardinality: (Fig 3)
 CARDINALITY & MODALITY TOGETHER
 Here is an illustration of modality. Notice that we can put both cardinality and modality on the
same line.
 Modality goes on the inside and cardinality goes on the outside. (Fig 4)
Fig 4

Fig 5

 Cardinality and modality together gives us four possible combinations: (Fig 5)

 Let’s apply this to the credit card example:
 Here are all of our options.
 The only thing to take into consideration is the fact
that
 We call the person a card holder even if he or she
doesn’t currently have a credit card.
 Itmay be best to either change the title “card
holder” to “customer”
 Or only use “at least one” to ensure that a a card
holder is currently holding a card.
 Refer Fig 6
CARDINALITY & MODALITY TOGETHER

The Modality of a relationship is 0 if there is explicitly

no need of a relationship or the said relationship is
optional.
The Modality is 1 if an occurrence of the relationship is
mandatory.
Cardinality is the maximum number of existing
connections between Table Rows which may be one or
many.
Modality also can have two options –
0 being the least OR 1 being the Least
Case Study
A local telephone company uses a software to
process requests for field services. A customer
complains of a problem. If on diagnosis it is
found that the problem is relatively simple, a
single repair action occurs.
However if it is is a complex problem then
multiple repair actions may be required.
The Relationship, Cardinality and Modality
between data objects, customer and the
corresponding repair action is given beside.
 Limitations of ER Diagrams and Models
 Only for relational data: Understand that the purpose is to show
relationships. ER diagrams show only that relational structure.
 Not for unstructured data: Unless the data is cleanly delineated
into different fields, rows or columns, ER diagrams are probably of
limited use. The same is true of semi-structured data, because only
some of the data will be useful.
 Difficultyintegrating with an existing database: Using ER
Models to integrate with an existing database can be a challenge
because of the different architectures.
 CASE STUDY FOR E-R DIAGRAM - I
 ER Diagram is known as Entity-Relationship Diagram,
 ER Diagram is used to analyze to the structure of the Database.
 ER Diagram shows relationships between entities and their attributes.
 An ER Model provides a means of communication.
 The Library Management System database keeps track of readers with the following
considerations –
 The system keeps track of the staff with a single point authentication system comprising login
Id and password.
 Staff maintains the book catalog with its ISBN, Book title, price(in INR), category(novel,
general, story), edition, author Number and details.
 A publisher has publisher Id, Year when the book was published, and name of the book.
 Readers are registered with their user_id, email, name (first name, last name), Phone no
(multiple entries allowed), communication address. The staff keeps track of readers.
 Readers can return/reserve books that stamps with issue date and return date. If not returned
within the prescribed time period, it may have a due date too.
 Staff also generate reports that has readers id, registration no of report, book no and return/issue
info.
ER Diagram of Library Management System
 ENTITIES, ATTRIBUTES RELATIONSHIPS
 This Library ER diagram illustrates key information about the Library, including entities such as staff,
readers, books, publishers, reports, and authentication system. It allows for understanding the
relationships between entities.

Entities and their Attributes –

 Book Entity : It has authno, isbn number, title, edition, category, price. ISBN is the Primary Key for
Book Entity.
 Reader Entity : It has UserId, Email, address, phone no, name. Name is composite attribute of
firstname and lastname. Phone no is multi valued attribute. UserId is the Primary Key for Readers
entity.
 Publisher Entity : It has PublisherId, Year of publication, name. PublisherID is the Primary Key.
 Authentication System Entity : It has LoginId and password with LoginID as Primary Key.
 Reports Entity : It has UserId, Reg_no, Book_no, Issue/Return date. Reg_no is the Primary Key of
reports entity.
 Staff Entity : It has name and staff_id with staff_id as Primary Key.
 Reserve/Return Relationship Set : It has three attributes: Reserve date, Due
date, Return date.

 Relationships between Entities –

 A reader can reserve N books but one book can be reserved by only one
reader. The relationship 1:N.
 A publisher can publish many books but a book is published by only one
publisher. The relationship 1:N.
 Staff keeps track of readers. The relationship is M:N.
 Staff maintains multiple reports. The relationship 1:N.
 Staff maintains multiple Books. The relationship 1:N.
 Authentication system provides login to multiple staffs. The relation is
1:N.
 CASE STUDY FOR E-R DIAGRAM - II
ERD Case Study Examples with solution for a university management
system will help you understand how to translate a business scenario into
database example.
We will design a University Database Management System  today , because it
is easy to understand the complete requirements for such scenario.
Before we rush towards designing  , lets get introduced to a very simple
technique to crack case study.  Use this and the whole entity-relation diagram
will be created before you know it.
There are four steps in designing a ERD for a DBMS .
1.IdentifyEntity and members
2.Decide relationships and Cardinality and Modality
3.Draw Entities separately
4.Connect relationships and entities
Now you know what to do with the user requirement ,  Just go through the entire case study
first and then apply these four steps on it.
ERD Case Study :

In a University  , there are several departments and each

department has a head of department who belongs to
Faculty. Department have a name , phone extension ,
specific mailing address and Students that belong to the
department. Students can belong to only one Department
at a time and Department can have more than one or no
Student.
Students and faculty have names and unique identification
numbers , with address , age , gender and other
information. Student studies different Courses offered by
University .
Faculty teaches these Courses . In each semester one student can
take more than one course and Faculty can teach more than one
courses . Faculty members can teach in multiple Departments.
Each course can be taught by many faculty members or no one.
Faculty members are also working on multiple research projects.
These projects are funded by government and university. One
project can have more than one faculty member and one faculty
member can work on more than one project.
Lets apply our four steps on this requirement. Think of them and
study this requirement again.
Identify Entity and Members  ;
Long ago ,  we told you how to identify entities . Remember? No? No worries  . 
You can find it  ERD Terminologies . Start identifying nouns in above statement and
make them bold characters.
In a University  , there are several departments and each department has a head of
department who belongs to Faculty. Department have a name , phone extension ,
specific mailing address and Students that belong to the department. Students can
belong to only one Department at a time and Department can have more than one
or no Student
Students and faculty have names and unique identification numbers , with address ,
age , gender and other information. Student studies different Courses offered
by University . Faculty teaches these Courses . In each semester one student can
take more than one course and Faculty can teach more than one courses . Faculty
members can teach in multiple Departments. Each course can be taught by many
faculty members or no one
Faculty members are also working on multiple research projects. These projects are
funded by government and university. One project can have more than one faculty
member and one faculty member can work on more than one project
Decide Relationships , Cardinality and Modality
No idea how to do it? Go  ERD Terminologies ERD Terminologies. Simply
identify verbs and identify them . Let’s make them bold Italic characters,
In a University  , there are several departments and each department has a
head of department who belongs to Faculty. Department have a name ,
phone extension , specific mailing address and Students that belong to the
department. Students can belong to only one Department at a time and
Department can have more than one or no Student
Students and faculty have names and unique identification numbers , with
address , age , gender and other information. Student studies different
Courses offered by University . Faculty teaches these Courses . In each
semester one student can take more than one course and Faculty can
teach more than one courses . Faculty members can teach in
multiple Departments. Each course can be taught by many faculty members
or no one
Faculty members are also working on multiple research projects. These
projects are funded by government and university. One project can have more
than one faculty member and one faculty member can work on more than
one project
Draw Entities  & Attribute Separately :
You may wonder about the members , as they can sometimes are
missing , so we add the missing attributes that are not in the
requirement by the knowledge of the industry we are designing the
DBMS for . A primary key is a must attribute for  every entity .
Student have Name , age , gender , address , phone Number , Roll
Number , Semester , Course_ID and Student_ID. Faculty have
Name , age , gender , address , phone Number ,  Semester ,
Course_ID, Grade , Salary , Faculty_ID and
designation. Course have Name , Code , Student_ID , Faculty_ID ,
Department_ID and Course_ID. Department have Name ,
Student_ID , Faculty_ID and Department_ID. Research Project –
Project_ID, Faculty_ID , Name , Duration.
 Create Relationships Between Entities.
 We know the relationships from above steps and also what will be the
cardinality and modality.
 If we have to read this diagram , this is how it will go . Reading symbols at
the other end
 Student-Department ; One Student Belongs to One and Only one
Department
 Department-Student : Department can have more than one student and no
Student. .
 Student-Course  : Student must have one course and can have more than
one.
 Course-Student : One course can be offered to many students or no
students at all
 Course-Faculty : One course can be taught by many faculty member or no
one
 Faculty-Course : One faculty member will teach one course or more than
one courses