Vibrant Technologies is headquarted in Mumbai,India.We are the best training provider in Navi Mumbai who provides Live Projects & online training as well as corporate training to students.We provide Corporate Training also.We are Best classes in Mumbai according to students and corporators
3. Overview of Database Design
• Requirements Analysis: Understand what data will be stored in the database, and the
operations it will be subject to.
• Conceptual Design: (ER Model is used at this stage.)
– What are the entities and relationships in the enterprise?
– What information about these entities and relationships should we store in the
database?
– What are the integrity constraints or business rules that hold?
– A database `schema’ in the ER Model can be represented pictorially (ER diagrams).
– Can map an ER diagram into a relational schema.
• Logical Design: Convert the conceptual database design into the data model underlying
the DBMS chosen for the application.
4. Overview of Database Design (cont.)
• Schema Refinement: (Normalization) Check relational schema for redundancies
and anomalies.
• Physical Database Design and Tuning: Consider typical workloads and further
refinement of the database design (v.g. build indices).
• Application and Security Design: Consider aspects of the application beyond
data. Methodologies like UML often used for addressing the complete software
development cycle.
5. ER Model Basics
• Entity: Real-world object distinguishable from other objects. An entity is
described using a set of attributes.
• Entity Set: A collection of entities of the same kind. E.g., all employees.
– All entities in an entity set have the same set of attributes.
– Each entity set has a key(a set of attributes uniquely identifying an
entity).
– Each attribute has a domain.
Employees
ssn
name
lot
6. ER Model Basics (Contd.)
• Relationship: Association among two or more entities. E.g., Peter works in Pharmacy department.
• Relationship Set: Collection of similar relationships.
– An n-ary relationship set R relates n entity sets E1 ... En; each relationship in R involves entities e1
∈ E1, ..., en ∈ En
– Same entity set could participate in different relationship sets, or in different “roles” in same set.
– Relationship sets can also have descriptive attributes (e.g., the since attribute of Works_In). A
relationship is uniquely identified by participating entities without reference to descriptive
attributes.
lot
dname
budgetdid
since
name
Works_In DepartmentsEmployees
ssn
name
Reports_To
lot
Employees
subor-
dinate
super-
visor
ssn
7. Key Constraints(a.k.a. Cardinality)
• Consider Works_In (in
previous slide): An employee
can work in many
departments; a dept can have
many employees.
• In contrast, each dept has at
most one manager, according
to the key constraint on
Manages.
Many-to-Many1-to-1 1-to Many Many-to-1
dname
budgetdid
since
lot
name
ssn
ManagesEmployees Departments
9. Participation Constraints• Does every department have a manager?
– If so, this is a participation constraint: the participation of Departments in
Manages is said to be total (vs. partial).
• Every Department MUST have at least an employee
• Every employee MUST work at least in one department
• There may exist employees managing no department
name dname
budgetdid
since
since
lot
name
Employees
ssn
since
Manages
Works_In
dname
budgetdid
Departments
10. Weak Entities
• A weak entity can be identified uniquely only by considering the primary key of another
(owner) entity.
– Owner entity set and weak entity set must participate in a one-to-many relationship
set (one owner, many weak entities).
– Weak entity sets must have total participation in this identifying relationship set.
– transac# is a discriminator within a group of transactions in an ATM.
since
address
amounttransac#
TransactionsATM
atmID
type
11. ISA (`is a’) Hierarchies
• Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? if so,
specify => Hourly_Emps OVERLAPS Contract_Emps.
• Covering constraints: Does every Employees’ entity also have to be an Hourly_Emps or a
Contract_Emps entity?. If so, write Hourly_Emps AND Contract_Emps COVER Employees.
As in C++, or other PLs, attributes
are inherited.
If we declare A ISA B, every A entity is
also considered to be a B entity.
» Reasons for using ISA:
To add descriptive attributes specific to a subclass.
To identify entities that participate in a relationship.
name
ssn lot
Contract_Emps
Employees
hourly_wages
Hourly_Emps
contractid
hours_worked
ISA
12. Aggregation
• Used when we have to model
a relationship involving (entity
sets and) a relationship set.
– Aggregation allows us to
treat a relationship set as
an entity set for
purposes of participation
in (other) relationships.
– Employees are assigned
to monitor
SPONSORSHIPS.
Aggregation vs. ternary relationship:
Monitors and Sponsors are distinct relationships, with descriptive attributes of their own.
Also, can say that each sponsorship
is monitored by at most one employee (which we cannot do with a ternary relationship).
budgetdidpid
started_on
dname
DepartmentsProjects Sponsors
pbudget
until
Employees
Monitors
lot
name
since
ssn
13. Conceptual Design Using the ER Model
• Design choices:
– Should a concept be modeled as an entity or an attribute?
– Should a concept be modeled as an entity or a relationship?
– Identifying relationships: Binary or ternary? Aggregation?
• Constraints in the ER Model:
– A lot of data semantics can (and should) be captured.
– But some constraints cannot be captured in ER diagrams.
14. Entity vs. Attribute
• Should address be an attribute of Employees or an entity (connected to
Employees by a relationship)?
• Depends upon the use we want to make of address information, and the
semantics of the data:
• If we have several addresses per employee, address must be an entity
(since attributes cannot be set-valued).
• If the structure (city, street, etc.) is important, e.g., we want to
retrieve employees in a given city, address must be modeled as an
entity (since attribute values are atomic).
15. Entity vs. Attribute (Contd.)
• Works_In4 does not allow an
employee to work in a
department for two or more
periods (a relationship is
identified by participating
entities).
• Similar to the problem of
wanting to record several
addresses for an employee: We
want to record several values of
the descriptive attributes for
each instance of this
relationship. Accomplished by
introducing new entity set,
Duration.
name
Employees
ssn lot
Works_In4
from to
dname
budgetdid
Departments
name
lotssn
from to
dname
budgetdid
Departments
Duration
Works_In4
Employees
16. Entity vs. Relationship
• First ER diagram OK if a manager
gets a separate discretionary
budget for each dept.
• What if a manager gets a
discretionary budget that covers
all managed depts?
– Redundancy: dbudget stored
for each dept managed by
manager.
– Misleading: Suggests dbudget
associated with department-
mgr combination.
Manages2
name dname
budgetdid
Employees Departments
ssn lot
dbudgetsince
Departments
did
Manages2
ssn lot
ISA
dname
budget
since
dbudget
Employees
name
Managers
17. Binary vs. Ternary
Relationships
• Suppose:
– A policy cannot be
owned by more than
one employee.
– Every policy must be
owned by some
employee.
– Dependent is a weak
entity set, identified
by policiId.
agepname
DependentsCovers
name
Employees
ssn lot
Policies
policyid cost
Beneficiary
age
pname
Dependents
policyid cost
Policies
Purchaser
name
Employees
ssn lot
Bad design
18. Binary vs. Ternary Relationships (Contd.)
• Previous example illustrated a case when two binary
relationships were better than one ternary relationship.
• An example in the other direction: a ternary relation Contracts
relates entity sets Parts, Departments and Suppliers, and has
descriptive attribute qty. No combination of binary
relationships is an adequate substitute:
– Although S “can-supply” P, D “needs” P, and D “deals-
with” S, all these do not imply that D has agreed to buy P
from S (because D could buy P from another supplier).
19. Summary of Conceptual Design
• Conceptual design follows requirements analysis,
– Yields a high-level description of data to be stored
• ER model popular for conceptual design
– Constructs are expressive, close to the way people think about their
applications.
• Basic constructs: entities, relationships, and attributes (of entities and
relationships).
• Some additional constructs: weak entities, ISA hierarchies, and aggregation.
• Note: There are many variations on ER model.
20. Summary of ER (Contd.)
• Several kinds of integrity constraints can be expressed in the ER model: key
constraints, participation constraints, and overlap/covering constraints for ISA
hierarchies. Some foreign key constraints are also implicit in the definition of a
relationship set.
– Some constraints (notably, functional dependencies) cannot be expressed in
the ER model.
– Constraints play an important role in determining the best database design for
an enterprise.
21. Thank You !!!Thank You !!!
For More Information click below link:
Follow Us on:
http://vibranttechnologies.co.in/datastage-classes-in-mumbai.html
Editor's Notes
The slides for this text are organized into chapters. This lecture covers Chapter 2.
Chapter 1: Introduction to Database Systems
Chapter 2: The Entity-Relationship Model
Chapter 3: The Relational Model
Chapter 4 (Part A): Relational Algebra
Chapter 4 (Part B): Relational Calculus
Chapter 5: SQL: Queries, Programming, Triggers
Chapter 6: Query-by-Example (QBE)
Chapter 7: Storing Data: Disks and Files
Chapter 8: File Organizations and Indexing
Chapter 9: Tree-Structured Indexing
Chapter 10: Hash-Based Indexing
Chapter 11: External Sorting
Chapter 12 (Part A): Evaluation of Relational Operators
Chapter 12 (Part B): Evaluation of Relational Operators: Other Techniques
Chapter 13: Introduction to Query Optimization
Chapter 14: A Typical Relational Optimizer
Chapter 15: Schema Refinement and Normal Forms
Chapter 16 (Part A): Physical Database Design
Chapter 16 (Part B): Database Tuning
Chapter 17: Security
Chapter 18: Transaction Management Overview
Chapter 19: Concurrency Control
Chapter 20: Crash Recovery
Chapter 21: Parallel and Distributed Databases
Chapter 22: Internet Databases
Chapter 23: Decision Support
Chapter 24: Data Mining
Chapter 25: Object-Database Systems
Chapter 26: Spatial Data Management
Chapter 27: Deductive Databases
Chapter 28: Additional Topics
The slides for this text are organized into several modules. Each lecture contains about enough material for a 1.25 hour class period. (The time estimate is very approximate--it will vary with the instructor, and lectures also differ in length; so use this as a rough guideline.) This covers Lectures 1 and 2 (of 6) in Module (5).
Module (1): Introduction (DBMS, Relational Model)
Module (2): Storage and File Organizations (Disks, Buffering, Indexes)
Module (3): Database Concepts (Relational Queries, DDL/ICs, Views and Security)
Module (4): Relational Implementation (Query Evaluation, Optimization)
Module (5): Database Design (ER Model, Normalization, Physical Design, Tuning)
Module (6): Transaction Processing (Concurrency Control, Recovery)
Module (7): Advanced Topics