Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

1.7 Database Design With E-R Model

Download as pdf or txt
Download as pdf or txt
You are on page 1of 8

DBMS :: UNIT-I

Database Design with E-R Model

The database design can be divided into six steps. The ER model is most relevant to the
first six steps.
1. Requirement analysis:
The very first step in the designing a database application is to understand what
data is to be stored in the database, which application must be built on top of it and
which operations are more frequent and subject to performance requirements. This
is usually an informal phase that involves discussions with user groups, the study
of the current operating environment and how it is expected to change.
2. Conceptual database design:
The information gathered in the requirement analysis step is used to develop a high
level description of the data to be stored in the database, along with the constraints
known to hold over this data. This step is often carried out using the ER model. The
goal is to create a simple description of the data that closely matches how users and
developers think of the data.
3. Logical database design:
We must choose a DBMS to implement our database design and convert the
conceptual database design into a database schema in the data model of the chosen
DBMS
4. Schema refinement:
This step in the database design is to analyze the collection of relations in our
relational database schema to identify potential problems and to refine it. In
contrast to the requirement analysis and conceptual design steps, which are
essentially subjective, schema refinement can be guided by some elegant and
powerful theory.
5. Physical database design:
In this step, we consider typical expected workloads that our database must
support and further refine the database design to ensure that it meets desired
performance criteria. This step may involve building indexes on some tables and
clustering some tables, or it may involve substantial redesign of parts of the
database schema.
6. Application and security design:
Any software project that involves a DBMS must consider aspects of the application
that go beyond the database itself. We must identify the entities(eg. Users and user
groups) and processes involved in the application. We must describe the role of
each entity in every process that is reflected in some application task, as part of the
complete workflow of the task. For each role, we must identify the part of the
database that must be accessible and the parts of the data that must not be
accessible and we must take steps to ensure that these access rules are enforced.

Department of IT :: SVECW 1
DBMS :: UNIT-I

E_R Model:
An entity–relationship model (ER model) is a systematic way of describing and
defining a business process. An ER model is typically implemented as a database.
The main components of E-R model are: entities, attributes, entity sets and
relationship sets.
Entity:
An entity can be a real-world object, either animate or inanimate, that can be easily
identifiable. For example, in a school database, students, teachers, classes, and
courses offered can be considered as entities. All these entities have some attributes
or properties that give them their identity.
Entity set:
An entity set is a collection of similar types of entities. An entity set may contain
entities with attribute sharing similar values. For example, a Students set may
contain all the students of a school; likewise a Teachers set may contain all the
teachers of a school from all faculties. Entity sets need not be disjoint.
Attributes
Entities are represented by means of their properties, called attributes. All
attributes have values. For example, a student entity may have name, class, and
age as attributes.

Domain of an attribute:
We must identify a domain of possible values for each attribute associated with the
entity set.
Example: The attribute name of Employees may be the set of 20 character strings
The company rates employees on a scale of 1 to 10, and stores in a field called rating; the
domain consists of integers 1 through 10

Types of Attributes
 Simple attribute: Simple attributes are atomic values, which cannot be divided
further. For example, a student's phone number is an atomic value of 10 digits.
 Composite attribute: Composite attributes are made of more than one simple
attribute. For example, a student's complete name may have first_name and
last_name.
 Derived attribute: Derived attributes are the attributes that do not exist in the
physical database, but their values are derived from other attributes present in the
database. For example, average_salary in a department should not be saved
directly in the database, instead it can be derived. For another example, age can be
derived from data_of_birth.
 Single-value attribute: Single-value attributes contain single value. For example −
Social_Security_Number.
 Multi-value attribute: Multi-value attributes may contain more than one values.
For example, a person can have more than one phone number, email_address, etc.
Department of IT :: SVECW 2
DBMS :: UNIT-I

 Key attributes: The attribute(s) which can be used to uniqueely identify a entity in
an entity set

Representation
presentation as ER Diagram
Diagram:
Consider the following student table:
Roll_no Name Age

1 Rama 19

2 Ramya 20

3 Raga 20

4 Roopa 21

This complete table is referred to as “Student Entity Set” and each row represents an
“entity”.

Here, Roll_no is a primary key that can identify each entity uniquely. Thus, by using
student’s roll number, a student can be identified uniquely.

Entity Sets
 An entity set is a set of same type of entities.
 An entity refers to any object having
having-
o Either a physical existence such as a particular person, office, house or car.
o Or a conceptual existence such as a school or a company.
 An entity set may be of the following two types
types-
o Strong entity set:
 A strong entity set possess its own primary key.
 It is represented using a single rectangle

Department of IT :: SVECW 3
DBMS :: UNIT-I

o Weak Entity Set


 A weak entity set do not possess its own primary key.
 It is represented using a double rectangle.

Relationship Set
o Relationship defines an association among several entities.
o A relationship set is a set of same type of relationships.
 A relationship set may be of the following two types
o Strong Relationship Set
Set-
 A strong relationship exists between two strong entity sets.
 It is represented using a diamond symbol.

o Weak Relationship Set


Set-
 A weak or identifying relationship exists between the strong and
weak entity set.
 It is represented using a double diamond symbol.

Example:

A relationship can also have descriptive attributes. Descriptive attributes are used to
record
ecord the information about the relationship rather than about any
an of the participating
entities.

This relationship is ternary because we must record an association between an employee,


a department and a location

Department of IT :: SVECW 4
DBMS :: UNIT-I

The entity sets that participate in a relrelationship


ationship need not be distinct; sometimes a
relationship might involve two entities in the same entity set.

Key Constraints
One-to-many:
Each department has atmost one manager, although each employee is allowed to manage
more than one department.
This is an example of key constraint – indicated in the ER diagram by using an arrow from
Departments to Manages

In the figure below, each department can be associated with several employees and
locations and each location can be associated with several employees and departments,
however each employee is associated with a single department and a single location.

Department of IT :: SVECW 5
DBMS :: UNIT-I

Binary Relationship and Cardinality:

A relationship where two entities are participating is called a binary relationship.


Cardinality is the number o
off instance of an entity from a relation that can be associated
with the relation.

 One-to-one − When only one instance of an entity is associated with the


relationship, it is marked as '1:1'. The following image reflects that only one
instance of each entit
entityy should be associated with the relationship. It depicts one-to-
one
one relationship.

 One-to-many − When more than one instance of an entity is associated with a


relationship, it is marked as '1:N'. The following image reflects that only one
instance of entity on the left and more than one instance of an entity on the right
can be associated with the relationship. It depicts one
one-to-many
many relationship.

 Many-to-one − When more than one instance of entity is associated with the
relationship, it is marked as 'N:1'. The following image reflects that more than one
instance of an entity on the left and only one instance of an entity on the right can
be associated with the relationship. It depicts many
many-to-one
one relationship.

 Many-to-many − The following image ref reflects


lects that more than one instance of an
entity on the left and more than one instance of an entity on the right can be
associated with the relationship. It depicts many
many-to-many
many relationship.

Department of IT :: SVECW 6
DBMS :: UNIT-I

Participation Constraints

 Participation constraint defines the least number of relationship instances in


which an entity has to necessarily participate.
 There are two types of participation constraints
constraints-
o Partial Participation
o Partial participation is represented using a single line between the
entity set and relationship set.

o
o Total Participation
Participation-
o Total participation is represented using a double line between the
entity set and relationship set.

Example:

Weak entity set – example

Department of IT :: SVECW 7
DBMS :: UNIT-I

Class hierarchies

Generalization:
Generalization is a bottom-up approach in which two lower level entities combine to
form a higher level entity. In generalization, the higher level entity can also combine with
other lower level entity to make further higher level entity.

Specialization:
Specialization is opposite to Generalization. It is a top-down approach in which one
higher level entity can be broken down into two lower level entities. In specialization,
some higher level entities may not have lower-level entity sets at all.

Aggregation:

Aggregation is a process when relation between two entity is treated as a single entity.
Here the relation between Center and Course, is acting as an Entity in relation with
Visitor.

Department of IT :: SVECW 8

You might also like