NAME:-Arjun Gondhali

BRANCH:-IT ROLL NO:-A44 ID:-TU4F2324050

Experiment : 1

Problem definition and ER diagram

Aim : Identify real world problem and develop the problem

statement .Design an Entity relationship(ER) model.
Theory: (a) defining problem for real life application .
(b) ER diagram notations
(a) defining problem for real life application ;
->for bank database system,
The initial specification of user required may be based on
interview with database users and the designers whole
analysis
of enterprises .The description that arises serves as the
basis for specifying the conceptual structure of
database.Here are the major characteristics ;
1. Description
The bank is organized into branches .Each branch is
located in a particular city and is identified by a unique name
.The bank monitor asset of each branch.
2.Customer
The bank customer identified as customer id values.The
bank stores each customers name and street and city where
the customer lives.Customers may have accounts and can
take out loan.the customer may be associated with the

banker who may act as personal or loan banker for the

customer.
3.Employee of the bank
Bank employee are identified by their employee id
values.The bank administrator stores name , telephone
number and name of employee dependent and employee id
no of the employee manager .The bank also keep track of
the employee start thus length of employment.
4.Account of the bank
The bank offers two type of account as Saving account and
Checking account .Account can be held by more than one
customer and customer can have more than one
account.Each account is assign a unique account
number.The bank maintain the record of each account value
and most recent date the account was accessed by each
customer holding account .In the addition behindeach
account overdrafts are recorded for each service account.
5.Loan service
a loan originates at a particular branch and can be held by
one or more customers .The loan is identified by unique
loan number . For each loan , the bank keeps track of loan
number and loan payment although the loan payment
number doesn’t uniquely identify a particular payment
among those . For all bank loans , a payment number does
identify a particular payment for specific loan.The date and
amount are recorded for each payment.
A requirement phase contains all of the above information.
(b) ER diagram notations :

An entity is a “thing” or “object” in the real world that is

distinguishable from all other objects. For example, each
person in an enterprise is an entity. An entity has a set of
properties, and the values for some set of properties may
uniquely identify an entity. For instance, a person may have
a person-id property whose value uniquely identifies that
person. Thus, the value 677-89-9011 for person-id would
uniquely identify one particular person in the enterprise.
Similarly, loans can be thought of as entities, and loan
number L-15 at the Perryridge branch uniquely identifies a
loan entity. An entity may be concrete, such as a person or
a book, or it may be abstract, such as a loan, or a holiday, or
a concept. An entity set is a set of entities of the same type
that share the same properties, or attributes. The set of all
persons who are customers at a given bank, for example,
can be defined as the entity set customer.
Entity sets do not need to be disjoint.Each entity has a value
for each of its attributes. For instance, a particular customer
entity may have the value 321-12-3123 for customer-id, the
value Jones for customername, the value Main for
customer-street, and the value Harrison for customer-city.
For each attribute, there is a set of permitted values, called
the domain, or value set, of that attribute. The domain of
attribute customer-name might be the set of all text strings
of a certain length. Similarly, the domain of attribute loan-
number might be the set of all strings of the form “L-n”
where n is a positive integer. A database thus includes a
collection of entity sets, each of which contains any number
of entities of the same type.
y, an attribute of an entity set is a function that maps from
the entity set into a domain. Since an entity set may have
several attributes, each entity can be described by a set of
(attribute, data value) pairs, one pair for each attribute of the
entity set. For example, a particular customer entity may be

described by the set {(customer-id, 677- 89-9011),

(customer-name, Hayes), (customer-street, Main),
(customer-city, Harrison)}, meaning that the entity describes
a person named Hayes whose customer identifier is 677-89-
9011 and who resides at Main Street in Harrison. We can
see, at this point, an integration of the abstract schema with
the actual enterprise being modeled. The attribute values
describing an entity will constitute a significant portion of the
data stored in the database.
In the ER model the attributes as of different types:
Simple and composite attributes:
Simple attributes are not divided into subparts.
. Composite attributes, on the other hand, can be divided
into subparts (that is, other attributes). For example, an
attribute name could be structured as a composite attribute
consisting of first-name, middle-initial, and last-name. Using
composite attributes in a design schema is a good choice if
a user will wish to refer to an entire attribute on some
occasions, and to only a component of the attribute on other
occasions. Suppose we were to substitute for the customer
entity-set attributes customer-street and customer-city the
composite attribute address with the attributes street, city,
state, and zip-code. 2 Composite attributes help us to group
together related attributes, making the modeling cleaner.
• Single-valued and multivalued attributes:
The loan-number attribute for a specific loan entity refers to
only one loan number. Such attributes are said to be single
valued.
There may be instances where an attribute has a set of
values for a specific entity. Consider an employee entity set
with the attribute phone-number. An employee may have
zero, one, or several phone numbers, and different

employees may have different numbers of phones. This

type of attribute is said to be multivalued.
Derived attribute:
The value for this type of attribute can be derived from the
values of other related attributes or entities. For instance, let
us say that the customer entity set has an attribute loans-
held, which represents how many loans a customer has
from the bank. We can derive the value for this attribute by
counting the number of loan entities associated with that
customer.
An attribute takes a null value when an entity does not have
a value for it. The null value may indicate “not
applicable”—that is, that the value does not exist for the
entity. For example, one may have no middle name. Null
can also designate that an attribute value is unknown. An
unknown value may be either missing (the value does exist,
but we do not have that information) or not known (we do
not know whether or not the value actually exists).
Relationship Sets:
A relationship set is a set of relationships of the same type.
Formally, it is a mathematical relation on n ≥ 2 (possibly
nondistinct) entity sets. If E1, E2,...,En are entity sets, then a
relationship set R is a subset of {(e1, e2,...,en) | e1 ∈ E1, e2
∈ E2,...,en ∈ En}
Constraints:
An E-R enterprise schema may define certain constraints to
which the contents of a database must conform. In this
section, we examine mapping cardinalities and participation
constraints, which are two of the most important types of
constraints.
Mapping Cardinalities:
Mapping cardinalities, or cardinality ratios, express the
number of entities to which another entity can be associated
via a relationship set. Mapping cardinalities are most useful
in describing binary relationship sets, although they can
contribute to the description of relationship sets that involve
more than two entity sets. In this section, we shall
concentrate on only binary relationship sets. For a binary
relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:
• One to one. An entity in A is associated with at most one
entity in B, and an entity in B is associated with at most one
entity in A.
• One to many. An entity in A is associated with any number
(zero or more) of entities in B. An entity in B, however, can
be associated with at most one entity in A.
• Many to one. An entity in A is associated with at most one
entity in B. An entity in B, however, can be associated with
any number (zero or more) of entities in A.
• Many to many. An entity in A is associated with any
number (zero or more) of
entities in B, and an entity in B is associated with any
number (zero or more)
of entities in A.
Keys:
A key allows us to identify a set of attributes that suffice to
distinguish entities from each other. Keys also help uniquely
identify relationships, and thus distinguish relationships from
each other.
A superkey is a set of one or more attributes that, taken
collectively, allow us to identify uniquely an entity in the
entity set.

The concept of a superkey is not sufficient for our purposes,

since, as we saw, a superkey may contain extraneous
attributes. If K is a superkey, then so is any superset of K.
We are often interested in superkeys for which no proper
subset is a superkey. Such minimal superkeys are called
candidate keys.
Entity-Relationship Diagram:
E-R diagram can express the overall logical structure of a
database graphically. E-R diagrams are simple and
clear—qualities that may well account in large part for the
widespread use of the E-R model. Such a diagram consists
of the following major components:
• Rectangles, which represent entity sets
• Ellipses, which represent attributes
• Diamonds, which represent relationship sets
• Lines, which link attributes to entity sets and entity sets to
relationship sets
• Double ellipses, which represent multivalued attributes
• Dashed ellipses, which denote derived attributes
• Double lines, which indicate total participation of an entity
in a relationship set
• Double rectangles, which represent weak entity sets.
Weak Entity Sets:
An entity set may not have sufficient attributes to form a
primary key. Such an entity set is termed a weak entity set.
Strong Entity Sets:
An entity set that has a primary key is termed a strong entity
set.
Discriminator:

The discriminator of a weak entity set is a set of attributes

that allows this distinction to be made. For example, the
discriminator of the weak entity set payment is the attribute
payment-number, since, for each loan, a payment number
uniquely identifies one single payment for that loan. The
discriminator of a weak entity set is also called the partial
key of the entity set.

ER notations:
Conclusion :
Thus we defined the problem and drawn the ER diagram of
bank database system.