Datastage database design and data modeling ppt 4

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.

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.

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

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

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

Key Constraints(ternary relationships)
dname
budgetdid
name
lot
name
ssn
works_InEmployees Departments
Location
•
•
•
•
12-233
12-243
12-354
12-299
D10
D13
D12
Rome
Paris
London
Each employee can work at
most in one department at
a single location

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

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

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

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

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.

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).

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

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

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

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).

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.

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.

Thank You !!!Thank You !!!
For More Information click below link:
Follow Us on:
http://vibranttechnologies.co.in/datastage-classes-in-mumbai.html

Datastage database design and data modeling ppt 4

Recommended

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to Datastage database design and data modeling ppt 4 (20)

More from Vibrant Technologies & Computers (20)

Recently uploaded (20)

Datastage database design and data modeling ppt 4

Editor's Notes