E - R Diagram

Data base design

• The task of creating a database application is a complex one,
involving design of the database schema, design of the programs
that access and update the data, and design of a security scheme to
control access to data. The needs of the users play a central role in
the design process.
• The design of a complete database application environment that
meets the needs of the enterprise being modeled requires attention
to a broad set of issues.
Design Phases
• For small applications, it may be feasible for a database designer who
understands the application requirements to decide directly on the
relations to be created, their attributes, and constraints on the
relations.
• However, such a direct design process is difficult for real-world
applications, since they are often highly complex.
• The database designer must interact with users of the application to
understand the needs of the application, represent them in a high-level
fashion that can be understood by the users, and then translate the
requirements into lower levels of the design.
Design Phases (contd.,)
• Initial phase -- characterize fully the data needs of the
prospective database users.
• The outcome of this phase is a specification of user
requirements.
• Second phase -- choosing a data model
• Applying the concepts of the chosen data model
• Translating these requirements into a conceptual
schema of the database.
• A fully developed conceptual schema indicates the
functional requirements of the enterprise.
• Describe the kinds of operations (or transactions)
that will be performed on the data.
Design Phases (contd.,)
 Final Phase -- Moving from an abstract data model to the implementation
of the database
• Logical Design – Deciding on the database schema.
• Database design requires that we find a “good” collection of relation
schemas.
 Business decision – What attributes should we record in the
database?
 Computer Science decision – What relation schemas should we
have and how should the attributes be distributed among the
various relation schemas?
• Physical Design – Deciding on the physical layout of the database
example
Initial phase:
For a university database, users say:
• Store student names, IDs, departments, and course enrollments.
• Generate report: "All students in a course."
• Prevent duplicate student IDs.
Second Phase:
Design an ER model:
Entities: Student, Course, Department
Relationships: Enrolls, Offers, BelongsTo
Attributes: StudentID, Name, Credits for Course, etc.
• Logical design (next level) -relational schema with tables, primary keys, and
foreign keys.
Entity: Student
StudentID (PK)
Name
DeptName (FK)

• Physical design: Decide how to store the data efficiently — choose indexes,
storage structures, file organization, etc.

• (Before physical design , normalization – refinement of schema to prevent

anomalies)
Design Alternatives
 In designing a database schema, we must ensure that we avoid two major pitfalls:
• Redundancy: a bad design may result in repeat information.
 Redundant representation of information may lead to data inconsistency
among the various copies of information
• Incompleteness: a bad design may make certain aspects of the enterprise
difficult or impossible to model.
 Avoiding bad designs is not enough. There may be a large number of good designs
from which we must choose a best design.
• The entity-relationship (E-R) data model was developed to facilitate
database design by allowing specification of an enterprise schema
that represents the overall logical structure of a database.
• The E-R model is very useful in mapping the meanings and
interactions of real-world enterprises onto a conceptual schema.The
E-R model is very useful in mapping the meanings and interactions of
real-world enterprises onto a conceptual schema.
Symbols
example
Entity
• An entity is a “thing” or “object” in the real world that is
distinguishable from all other objects. For example, each person in a
university is an entity.
• An entity set is a set of entities of the same type that share the same
properties, or attributes.
• An entity set that does not have sufficient attributes to form a
primary key is termed a weak entity set. An entity set that has a
primary key is termed a strong entity set.
• The relationship associating the weak entity set with the identifying
entity set is called the identifying relationship.
Weak entity example
• Course (Strong Entity)
Attributes: CourseID, CourseName
• Section (Weak Entity)
Attributes: SectionNumber, Instructor, Schedule
Attribute
• An entity is represented by a set of attributes. Attributes are
descriptive properties possessed by each member of an entity set
Relationship
• A relationship is an association among several entities. For example,
we can define a relationship advisor that associates instructor Katz
with student Shankar. This relationship specifies that Katz is an advisor
to student Shankar
• A relationship may also have attributes called descriptive attributes.
Consider a relationship set advisor with entity sets instructor and
student. We could associate the attribute date with that relationship
to specify the date when an instructor became the advisor of a
student
Attributes types
• Simple / composite
• Single/multivalued
• Derived

• The address can be defined as the composite attribute address with the attributes
street, city, state, and zip code. 3 Composite attributes help us to group together
related attributes, making the modeling cleaner.
• An instructor may have zero, one, or several phone numbers, and different instructors
may have different numbers of phones. This type of attribute is said to be multivalued
• age is a derived attribute. In this case, date of birth may be referred to as a base
attribute, or a stored attribute
Source : Elmasri book