Database Design and E-R Model

Overview of the design process

The task of creating database application is complex one, involving several tasks
such as

1.design of database schema

2.Design of the program that accesses and update data
3.Design of the security scheme.

Design phase:

•For small application, database designer will decide the requirements of the
user.

•In case of real world application single person can not understand the
complete data needs of the application.

•The database designer must interact with the user of the application to
understand the needs.
Requirement gathering: The initial phase of the database design is to
characterized the user requirements.

•The database designer must interact with the user of the application to
understand the needs.

•Next, the designer chooses the data model, and translate these requirements
into a schema of database.

•E-R model is used to represent the database design.

•E-R model represents the entities used ,their attributes and relationship
between the entities.

•E-R model provides the graphical representation of schema.

•In specification of functional requirement user describes the kind of operation

that will be performed on the data.
 Entity-Relationship Model
•The entity-relationship (E-R) data model perceives the real world as
consisting of basic objects, called entities, and relationships among these
objects.
•It represents the overall logical structure of a database.

•The E-R data model employs three basic notions:

1.entity sets
2. relationship sets
3.attributes.

Entity Sets:
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.
•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.

•An entity is represented by a set of attributes.

•Attributes are descriptive properties possessed by each member of an entity set.

•Possible attributes of the customer entity set are customer-id, customer-name, customer
street, and customer-city.

•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 customer
name.

•The customer-id attribute is used to uniquely identify customers, since there may be more
than one customer with the same name, street, and 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.
 Types of attributes
1) Simple and composite attributes.
•Simple attributes are not divided into subparts.
•Eg:-age,gender
•Composite attributes, on the other hand, can be divided into subparts
•For example, an attribute name could be structured as a composite attribute
consisting of first-name, middle-initial, and last-name.
•attribute ADDRESS can be subdivided into street, city, state, and zip
code.

Simple Attribute: Attribute that consist of a single atomic value.

Example: Salary, age etc

Composite Attribute  : Attribute value not atomic.

Example :   Address  :  ‘House_no:City:State
                  Name      :  ‘First Name: Middle Name: Last Name’
2) Single-valued and multi-valued attributes.
• The attributes in our examples all have a single value for a particular
entity.
• For instance, the loan-number attribute for a specific loan entity refers to
only one loan number.
• Eg:-
Single Valued Attribute: Attribute that hold a single value
Example1: age (date of birth) which can be composite
Exampe2: City
Example3:Customer id
• Such attributes are said to be single valued.
• There may be instances where an attribute has a set of values for a
specific entity.
• Multi Valued Attribute: Attribute that hold multiple values.
Example1: A customer can have multiple phone numbers, email id's etc
Example2: A person may have several college degrees
• This type of attribute is said to be multi-valued.
Derived attribute

• The value for this type of attribute can be derived from the values of other
related attributes or entities.

•As another example, suppose that the customer entity set has an attribute
•age, which indicates the customer’s age.

• If the customer entity set also has an attribute date-of-birth, we can calculate
age from date-of-birth and the current date.

• Thus, age is a derived attribute.

•In this case, date-of-birth may be referred to as a base attribute.

•An attribute takes a null value when an entity does not have a value for it.
Relationship Sets

A relationship is an association among several entities.

A relationship set is a set of relationships of the same type.

Consider the two entity sets customer and loan .

We define the relationship set borrower to denote the association between

customers and the bank loans that the customers have.
•A relationship may also have attributes called descriptive attributes.

• Consider a relationship set depositor with entity sets customer and account.

•We could associate the attribute access-date to that relationship to specify the
most recent date on which a customer accessed an account.
 Constraints
Mapping Cardinalities

Mapping cardinalities, or cardinality ratios, express the number of entities to

which another entity can be associated via a relationship set.
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.

1 1
Department has Manager
1 1
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.

Manager super Employee

vises

•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.
Works
Employee on project
C) Many to one
The key is defined as the column or attribute of the database table. For example if
a table has id,name and address as the column names then each one is known as
the key for that table. We can also say that the table has 3 keys as id, name and
address. The keys are also used to identify each record in the database table.The
following are the various types of keys available in the DBMS system.
 Superkey
A superkey is a combination of columns that uniquely identifies any row
within a relational database management system (RDBMS) table
For example, imagine a table used to store customer master details that
contains columns such as:
• Customer name
• Customer ID
• Social security number (SSN)
• Address
• Date of birth
A certain set of columns may be extracted and guaranteed unique to each
customer. Examples of superkeys are as follows:
• Name+SSN+Birthdate
• ID+Name+SSN
• However, this process may be further reduced. It can be assumed that each
customer ID is unique to each customer. So, the superkey may be reduced to
just one field, customer ID, which is the candidate key.
 What is a Primary Key?
• Definition: The primary key of a relational table uniquely identifies each record in
the table. It can either be a normal attribute that is guaranteed to be unique (such
as Social Security Number in a table
• A primary key’s main features are:
• It must contain a unique value for each row of data.
• It cannot contain null values.
• A primary key is either an existing table column or a column that is specifically
generated by the database according to a defined sequence.
 Entity-Relationship Diagram
An E-R diagram can express the overall logical structure of a database graphically.

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
•Above ERD consists of two entity sets, customer and loan, related through a
binary relationship set borrower.

•The attributes associated with customer are customer-id, customer-name,

customer-street, and customer-city.

• The attributes associated with loan are loan-number and amount.

•Above figure shows how composite attributes can be represented in the E-R
notation.

•Here, a composite attribute name, with component attributes first-name,

middle-initial, and last-name replaces the simple attribute customer-name of
customer.

• Also, a composite attribute address, whose component attributes are

street, city, state, and zip-code replaces the attributes customer-street and
customer-city of customer.

• The attribute street is itself a composite attribute whose component

attributes are street-number, street-name, and apartment number.
 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.

• An entity set that has a primary key is termed a strong entity set.

•consider the entity set payment, which has the three attributes:
•payment-number, payment-date, and payment-amount.

• Payment numbers are typically sequential numbers, starting from 1,

generated separately for each loan.

•Thus, although each payment entity is distinct, payments for different loans
may share the same payment number.

•Thus, this entity set does not have a primary key; it is a weak
•entity set.
•For a weak entity set to be meaningful, it must be associated with another
entity set, called the identifying or owner entity set.

• Every weak entity must be associated with an identifying entity; that is, the
weak entity set is said to be existence dependent on the identifying entity set.

•The identifying entity set is said to own the weak entity set that it identifies.

•The relationship associating the weak entity set with the identifying entity
set is called the identifying relationship.

•In our example, the identifying entity set for payment is loan, and a
relationship loan-payment that associates payment entities with their
corresponding loan entities is the identifying relationship.
•Although a weak entity set does not have a primary key, we nevertheless
need a means of distinguishing among all those entities in the weak entity set
that depend on one particular strong entity.

•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.
 Design Issues

Use of Entity Sets versus Attributes

• Consider the entity set employee with attributes employee-name and

telephone-number.

• It can easily be argued that a telephone is an entity in its own right with
attributes telephone-number and location .

• If we take this point of view, we must redefine the employee entity set as:

1. • The employee entity set with attribute employee-name

2. • The telephone entity set with attributes telephone-number and location
3. • The relationship set emp-telephone, which denotes the association
between employees and the telephones that they have
 Emp_name Emp_street

Emp_id Telephone_num

Employee

Emp_name location
Emp_street
Telephone_num
Telephone_num
Emp_id
Em
Employee p_ Telephone
te
l

•Treating a telephone as an attribute telephone-number implies that employees have

precisely one telephone number each.

• Treating a telephone as an entity telephone permits employees to have several

telephone numbers (including zero) associated with them.
Use of Entity Sets versus Relationship Sets

It is not always clear whether an object is best expressed by an entity set or a relationship
set.

we assumed that a bank loan is modeled as an entity.

An alternative is to model a loan not as an entity, but rather as a relationship between
customers and branches, with loan-number and amount as descriptive attributes. Each
loan is represented by a relationship between a customer and a branch

If every loan is held by exactly one customer and is associated with exactly one
branch, we may find satisfactory the design where a loan is represented as a relationship.
However, with this design, we cannot represent conveniently a situation in
which several customers hold a loan jointly. To handle such a situation, we must define
a separate relationship for each holder of the joint loan. Then, we must replicate
the values for the descriptive attributes loan-number and amount in each such
relationship.
 c_name c_street name

city
c_id
loa branch
customer n
Reduction to relational schemas

We can represent a database that conforms to an E-R database schema by a collection

of tables. For each entity set and for each relationship set in the database, there is a
unique table to which we assign the name of the corresponding entity set or
relationship
set. Each table has multiple columns, each of which has a unique name.

we can convert an E-R design into a relational design.

Tabular Representation of Strong Entity Sets

As an illustration, consider the entity set loan of the E-R diagram in Figure 2.8. This
entity set has two attributes: loan-number and amount. We represent this entity set by
a table called loan, with two columns
 c_name
c_street

c_id
C_city
customer
Tabular Representation of Weak Entity Sets

consider the entity set payment

This entity set has three attributes: payment-number, payment-date, andpayment-

amount.

The primary key of the loan entity set, on which payment depends, is loan-number.

Thus, we represent payment by a table with four columns labeled loan-number, payment
number, payment-date, and payment-amount,
 Codd’s 12 rules
• The rules are designed to define what is required from a
database management system in order for it to be considered
relational
Rule zero: the rule state that for system to be qualified as
RDBMS ,it must be able to manage database entirely through
the relational capabilities.-
Rule 1: The information rule:
This rule states that all information (data), which is stored in
the database, must be a value of some table cell. Everything in
a database must be stored in table formats. This information
can be user data or meta-data.
Rule 2: The guaranteed access rule:
All data should be accessible without ambiguity. This means
each data item can be uniquely identified using the table name,
primary key, and column name
Rule 3: Systematic treatment of null values:

•The DBMS must allow each field to remain null (or empty).
• A column should be allowed to remain empty.
•"Empty" means containing absolutely nothing, in other words, a
null value, which is distinct from a spaces or a number with a value
of zero.
•Null have several meaning,it can be for missing data,not
applicable or no value.primary key should not be null.

Rule 4: The DBMS must provide access to its structure through the
same tools that are used to access the data.

This is accomplished by storing the structure definition within tables,

the same as data is stored.
Rule 5: The comprehensive data sublanguage rule:
•The DBMS must support a clearly defined language that includes
functionality for data definition, data manipulation, data integrity, and
database transaction control.

•Relational databases use forms of standard SQL as their supported

comprehensive language.

Rule 6: The view updating rule:

Data can be presented to the user in different logical combinations called
views.

Rule 7: High-level insert, update, and delete:

The system must support insert, update, and delete operators.

This means that data can be retrieved from a relational database in sets
constructed of data from multiple rows and/or multiple tables.

This rule states that insert, update, and delete operations should be supported for
any retrievable set rather than just for a single row in a single table.
Rule 8: Physical data independence:
The user is isolated from the physical method of storing and retrieving
information from the database.

Rule 9: Logical data independence:

•Changes to the logical level (tables, columns, rows, and so on) must not
require a change to an application based on the structure

•How a user views data should not change when the logical structure
(tables structure) of the database changes.

• This is hard to implement practically, but database implementation do

make some types of changes “transparent” to data users.

•For example, adding columns to a table does not affect existing uses of
columns already present
Rule 10: Integrity independence:
•Constraints on user input must be provided to maintain database
integrity.

•Database implementations at least must insure that no part of a primary

key is missing (null) and that if a foreign key is defined in one table, the
value in it must exist as a primary key in another table.

Rule 11: Distribution independence:

The distribution of portions of the database to various locations
should be invisible to users of the database. Existing applications
should continue to operate successfully :

Rule 12: Users should be no way to modify the database structure other
than through the multiple row database language (SQL).
 Introduction to uml diagram
• The UML is an international industry standard
graphical notation for describing software
analysis and designs. When a standardized
notation is used, there is little room for
misinterpretation and ambiguity.
• Four types of uml diagram:
1)Use case daigram
2)Class diagram
3)Activity diagram
 Use case diagram
• Use case diagrams model the functionality of a
system using actors and use cases. Use cases are
services or functions provided by the system to its
users.
System
• Draw your system's boundaries using a rectangle that
contains use cases. Place actors outside the system's
boundaries.
Use Case
• Draw use cases using ovals. Label with ovals
with verbs that represent the system's
functions.
Actors
• Actors are the users of a system. When one
system is the actor of another system, label
the actor system with the actor stereotype.
Relationships
• Illustrate relationships between an actor and a use case with
a simple line. For relationships among use cases, use arrows
labeled either "uses" or "extends." A "uses" relationship
indicates that one use case is needed by another in order to
perform a task. An "extends" relationship indicates
alternative options under a certain use case.
 Class diagram
• Class diagrams are the backbone of almost every object-
oriented method including UML. The
• A class is shown as a solid-outline rectangle containing the
class name, and optionally with compartments separated by
horizontal lines containing features or other members of the
classifier. y describe the static structure of a system.
• As class is the most widely used classifier, there is no need to
add the "class" keyword. Class name should be centered and
in bold face, with the first letter of class name capitalized
• Features of class are attribute and operation.
• When class is shown with three compartments, the middle
compartment holds a list of attributes and the bottom
compartment holds a list of operations. Attributes and
operations should be left justified in plain face, with the first
letter of the names in lower case.
 Activity diagram
• Activity diagram is basically a flow chart to represent the flow
form one activity to another activity. The activity can be
described as an operation of the system.
Action states
• Action states represent the noninterruptible actions of
objects. You can draw an action state in SmartDraw using a
rectangle with rounded corners.
• Action Flow
• Action flow arrows illustrate the relationships
among action states.
• Object Flow
• Object flow refers to the creation and modification of objects
by activities.
• An object flow arrow from an action to an object means that
the action creates or influences the object.
• An object flow arrow from an object to an action indicates
that the action state uses the object.
• Initial State
A filled circle followed by an arrow represents
the initial action state

Final State
An arrow pointing to a filled circle nested inside another circle
represents the final action state.
• Branching
A diamond represents a decision with alternate
paths. The outgoing alternates should be
labeled with a condition or guard expression.
You can also label one of the paths "else.“