P. 1
Lecture 2

Lecture 2

|Views: 6|Likes:
Published by Prabhat Chandra

More info:

Published by: Prabhat Chandra on Feb 23, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less

02/23/2012

pdf

text

original

CMSC424: Database Design

Instructor: Amol Deshpande amol@cs.umd.edu

CMSC424, Spring 2005

Data Modeling
‡ Goals:
‡ Conceptual representation of the data ‡ ³Reality´ meets ³bits and bytes´ ‡ Must make sense, and be usable by other people

‡ Today:
‡ Entity-relationship Model ‡ Relational Model

CMSC424, Spring 2005

Motivation
‡ You¶ve just been hired by Bank of America as their DBA for their online banking web site. ‡ You are asked to create a database that monitors:
‡ ‡ ‡ ‡ ‡ customers accounts loans branches transactions, «

‡ Now what??!!!

CMSC424, Spring 2005

Database Design Steps
Entity-relationship Model Typically used for conceptual database design
info
Conceptual DB design

Three Levels of Modeling

Conceptual Data Model

Logical DB design

Logical Data Model

Relational Model Typically used for logical database design
CMSC424, Spring 2005

Physical DB design

Physical Data Model
4

Entity-Relationship Model
‡ Two key concepts
‡ Entities:
‡ An object that exists and is distinguishable from other objects
‡ Examples: Bob Smith, BofA, CMSC424

‡ Have attributes (people have names and addresses) ‡ Form entity sets with other entities of the same type that share the same properties
‡ Set of all people, set of all classes

‡ Entity sets may overlap
‡ Customers and Employees

CMSC424, Spring 2005

Spring 2005 .Entity-Relationship Model ‡ Two key concepts ‡ Relationships: ‡ Relate 2 or more entities ‡ E.g. Bob Smith has account at College Park Branch ‡ Form relationship sets with other relationships of the same type that share the same properties ‡ Customers have accounts at Branches ‡ Can have attributes: ‡ has account at may have an attribute start-date ‡ Can involve more than 2 entities ‡ Employee works at Branch at Job CMSC424.

Spring 2005 7 .ER Diagram: Starting Example access-date cust-name number cust-id customer cust-street has account cust-city balance ‡ Rectangles: entity sets ‡ Diamonds: relationship sets ‡ Ellipses: attributes CMSC424.

Spring 2005 . ‡ Design issues ‡ A detailed example CMSC424.Rest of the class ‡ Details of the ER Model ‡ How to represent various types of constraints/semantic information etc.

the domain knowledge may be lost CMSC424. Spring 2005 .Next: Relationship Cardinalities ‡ We may know: One customer can only open one account OR One customer can open multiple accounts ‡ Representing this is important ‡ Why ? ‡ Better manipulation of data ‡ Can enforce such a constraint ‡ Remember: If not represented in conceptual model.

Mapping Cardinalities ‡ Express the number of entities to which another entity can be associated via a relationship set ‡ Most useful in describing binary relationship sets CMSC424. Spring 2005 .

Spring 2005 .Mapping Cardinalities ‡ One-to-One ‡ One-to-Many ‡ Many-to-One ‡ Many-to-Many customer has account customer has account customer has account customer has account CMSC424.

Mapping Cardinalities ‡ Express the number of entities to which another entity can be associated via a relationship set ‡ Most useful in describing binary relationship sets ‡ N-ary relationships ? CMSC424. Spring 2005 .

age can be derived ‡ Can help in avoiding redundancy. enforcing constraints etc« CMSC424.g. Spring 2005 . Phone numbers are multi-valued ‡ Derived ‡ If date-of-birth is present.Next: Types of Attributes ‡ Simple vs Composite ‡ Single value per attribute ? ‡ Single-valued vs Multi-valued ‡ E.

Types of Attributes access-date cust-name number cust-id customer cust-street has account cust-city balance CMSC424. Spring 2005 .

balance CMSC424.Types of Attributes age cust-name ‡ multi-valued (double ellipse) access-date ‡ derived (dashed ellipse) number cust-id date-of-birth cust-street customer has account cust-city phone no. Spring 2005 .

balance Composite Attribute CMSC424. Spring 2005 .Types of Attributes age cust-name access-date number cust-id date-of-birth cust-street customer has account month day cust-city year phone no.

Spring 2005 .Next: Keys ‡ Key = set of attributes identifying individual entities or relationships CMSC424.

Entity Keys Possible Keys: date-of-birth cust-name {cust-id} {cust-name. Spring 2005 . age cust-street customer Domain knowledge dependent !! cust-city phone no. age} cust-id cust-name ?? Probably not. CMSC424. cust-street} {cust-id. cust-city.

Spring 2005 . cust-city. age} not a superkey ‡ {cust-name. cust-street} is ‡ assuming cust-name is not unique ‡ Primary key ‡ Candidate key chosen as the key by DBA ‡ Underlined in the ER Diagram CMSC424.Entity Keys ‡ Superkey ‡ any attribute set that can distinguish entities ‡ Candidate key ‡ a minimal superkey ‡ Can¶t remove any attribute and preserve key-ness ‡ {cust-id.

g. something involving address not a great idea cust-city phone no. Spring 2005 . SSN forms a good primary key ‡ Try to use a candidate key that rarely changes cust-id age cust-street customer ‡ e.Entity Keys ‡ {cust-id} is a natural primary key date-of-birth cust-name ‡ Typically. CMSC424.

account number} describes a relationship completely CMSC424. and relationship attributes access-date cust-id number customer has account ‡ {cust-id. Spring 2005 . access-date.Relationship Set Keys ‡ What attributes are needed to represent a relationship completely and uniquely ? ‡ Union of primary keys of the entities involved.

account number} a candidate key ? ‡ No. Spring 2005 . access-date. union of primary keys of associated entities is always a superkey access-date cust-id number customer has account CMSC424.Relationship Set Keys ‡ Is {cust-id. Attribute access-date can be removed from this set without losing key-ness ‡ In fact.

Spring 2005 . account-number} a candidate key ? ‡ Depends access-date cust-id number customer has account CMSC424.Relationship Set Keys ‡ Is {cust-id.

either {cust-id} or {account-number} sufficient ‡ Since a given customer can only have one account. account-number} a candidate key ? ‡ Depends access-date cust-id number customer has account ‡ If one-to-one relationship. she can only participate in one relationship ‡ Ditto account CMSC424. Spring 2005 .Relationship Set Keys ‡ Is {cust-id.

account-number} a candidate key ? ‡ Depends access-date cust-id number customer has account ‡ If one-to-many relationship (as shown).Relationship Set Keys ‡ Is {cust-id. Spring 2005 . but at most one account holder per account allowed CMSC424. {account-number} is a candidate key ‡ A given customer can have many accounts.

Spring 2005 .Relationship Set Keys ‡ General rule for binary relationships ‡ one-to-one: primary key of either entity set ‡ one-to-many: primary key of the entity set on the many side ‡ many-to-many: union of primary keys of the associate entity sets ‡ n-ary relationships ‡ More complicated rules CMSC424.

Next: Data Constraints ‡ Representing semantic data constraints ‡ We already saw constraints on relationship cardinalities CMSC424. Spring 2005 .

Participation Constraint ‡ Given an entity set E. Spring 2005 . and a relationship R it participates in: ‡ If every entity in E participates in at least one relationship in R. it is total participation ‡ partial otherwise CMSC424.

Spring 2005 29 .Participation Constraint access-date cust-name number cust-id customer cust-street has account cust-city balance Total participation CMSC424.

.1 CMSC424.1 account Minimum .* has 1. Spring 2005 ..Cardinality Constraints How many relationships can an entity participate in ? access-date cust-id number customer 0.0 Maximum ± no limit Minimum .1 Maximum .

Spring 2005 .Next: Recursive Relationships ‡ Sometimes a relationship associates an entity set to itself CMSC424.

Recursive Relationships emp-name emp-id manager employee worker emp-street works-for emp-city Must be declared with roles CMSC424. Spring 2005 .

transaction-date. transaction-amount.Next: Weak Entity Sets ‡ An entity set without enough attributes to have a primary key ‡ E. Spring 2005 . Transaction Entity ‡ Attributes: ‡ transaction-number. transaction-type ‡ transaction-number: may not be unique across accounts CMSC424.g.

Spring 2005 .Weak Entity Sets ‡ A weak entity set must be associated with an identifying or owner entity set ‡ Account is the owner entity set for Transaction CMSC424.

Weak Entity Sets Still need to be able to distinguish between different weak entities associated with the same strong entity number trans-date trans-number account has Transaction trans-type balance trans-amt CMSC424. Spring 2005 .

Weak Entity Sets Discriminator: A set of attributes that can be used for that number trans-date trans-number account has Transaction trans-type balance trans-amt CMSC424. Spring 2005 .

transaction-number} CMSC424.Weak Entity Sets ‡ Primary key: ‡ Primary key of the associated strong entity + discriminator attribute set ‡ For Transaction: ‡ {account-number. Spring 2005 .

credit-rating ‡ employee ‡ Additional attributes: employee-id. city ‡ Further classification: ‡ customer ‡ Additional attributes: customer-id. Spring 2005 .Next: Specialization ‡ Consider entity person: ‡ Attributes: name. salary ‡ Note similarities to object-oriented programming CMSC424. street.

Specialization: Example CMSC424. Spring 2005 .

g.: Associate account officers with has account relationship set customer has account ? account officer employee CMSC424.Finally: Aggregation ‡ No relationships between relationships ‡ E. Spring 2005 .

Finally: Aggregation ‡ Associate an account officer with each account ? ‡ What if different customers for the same account can have different account officers ? customer has account ? account officer employee CMSC424. Spring 2005 .

Finally: Aggregation ‡ Solution: Aggregation customer has account account officer employee CMSC424. Spring 2005 .

More« ‡ Read Chapter 2 for: ‡ Specialization/Aggregation details ‡ Different types of specialization¶s etc ‡ ‡ ‡ ‡ Generalization: opposite of specialization Lower.and higher-level entities Attribute inheritance « CMSC424. Spring 2005 .

then (b)) 2. Can many employees share a phone? (If yes. Can employees have multiple phones? (if yes. or (a) with multivalued attributes) Employee phone no loc 3. Else (a).E/R Data Model Design Issue #1: Entity Sets vs. Spring 2005 . determine how phones are used 1. Attributes An Example: Employees can have multiple phones (a) Employee phone_no phone_loc (b) vs Employee Uses no Phone loc To resolve. then (b). perhaps with composite attributes CMSC424.

potential update anomalies) 2.E/R Data Model Design Issue #2: Entity Sets vs. (hence (a) probably more appropriate) CMSC424. Spring 2005 . Relationship Sets An Example: How to model bank loans Customer ssn Borrows (a) lno Loan amt vs Customer ssn name Loans Branch bname amt bcity name lno (b) To resolve. then (a). loan info must be replicated for each customer (wasteful. determine how loans are issued 1. Is loan a noun or a verb? ‡ Both. Can there be more than one customer per loan? ‡ If yes. but more of a noun to a bank. Otherwise.

Spring 2005 . w3)  WAB (Acct. w3)  WAD CMSC424. Moody. update anomalies) (Joe.E/R Data Model Design Issue #3: N-ary vs Binary Relationship Sets An Example: Works_At Ternary: Employee Works_at Dept Branch Choose n-ary when possible! (Avoids redundancy. w3)  WAE (Moody. Acct)  Works_At vs Binary: Employee WAE WA WAD WAB Branch Dept (Joe.

Example Design ‡ We will model a university database ‡ Main entities: ‡ ‡ ‡ ‡ ‡ Professor Projects Departments Graduate students etc« CMSC424. Spring 2005 .

SSN name proj-number sponsor professor area rank project start budget dept-no name SSN name dept office homepage grad age degree CMSC424. Spring 2005 .

SSN name proj-number sponsor professor area rank project start budget dept-no name SSN name dept office homepage grad age degree CMSC424. Spring 2005 .

Spring 2005 Mentor .SSN name area rank proj-number PI professor sponsor project start budget Co-PI Chair Appt Supervises RA Time (%) dept-no name SSN name dept office homepage grad Major advisee advisor age degree CMSC424.

Spring 2005 Mentor .SSN name area rank proj-number PI professor sponsor project start budget Co-PI Chair Appt Supervises RA Time (%) dept-no name SSN name dept office homepage grad Major advisee advisor age degree CMSC424.

SSN name area rank proj-number PI professor sponsor project start budget Co-PI Chair Appt Supervises RA Time (%) dept-no name SSN name dept office homepage grad Major advisee advisor age degree And so on« CMSC424. Spring 2005 Mentor .

Summary ‡ Entity-relationship Model ‡ Intuitive diagram-based representation of domain knowledge. Spring 2005 . data properties etc« ‡ Two key concepts: ‡ Entities ‡ Relationships ‡ We also looked at: ‡ ‡ ‡ ‡ Relationship cardinalities Keys Participation Constraints « CMSC424.

Summary ‡ Details unimportant ‡ Key idea: We can represent many data properties and constraints conceptually using this ‡ Read Chapter 2 ‡ Assignment will require you to do this anyway ! CMSC424. Spring 2005 .

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->