CPSC-310 Database Systems

CPSC-310 Database Systems
Professor Jianer Chen Room 315C HRBB Lecture #4

From E/R Diagrams to Relations (Converting E/R diagrams into tables)

an entity set  a relation (attributes  attributes). E/R diagram Relation Beers name manf Beers(name, manf)

an entity set  a relation (attributes  attributes). a relationship  a relation with attributes: * keys of the connected entity sets. * attributes of the relationship itself. E/R diagram Drinkers Beers Likes Favorite Married husband wife name addr manf Buddies 1 2 Relations Likes(drinker, beer) Favorite(drinker, beer) Buddies(name1, name2) Married(husband, wife)

Combining Relations

Combining Relations OK to combine into one relation if:

Combining Relations OK to combine into one relation if: * The relation for an entity set E * The relations for many-one relationships where E is the “many.”

Combining Relations OK to combine into one relation if: * The relation for an entity set E * The relations for many-one relationships where E is the “many.” Example: Drinkers(name, addr) and Favorite(drinker, beer)

Combining Relations OK to combine into one relation if: * The relation for an entity set E * The relations for many-one relationships where E is the “many.” Example: Drinkers(name, addr) and Favorite(drinker, beer) Drinkers(name, addr) Drinkers name addr Beers manf Favorite Favorite(drinker, beer)

Combining Relations OK to combine into one relation if: * The relation for an entity set E * The relations for many-one relationships where E is the “many.” Example: Drinkers(name, addr) and Favorite(drinker, beer) combine to make Drinkers1(name, addr, favBeer). Drinkers(name, addr) Drinkers1(name, addr, favBeer) + Favorite(drinker, beer)

Combining Relations OK to combine into one relation if: * The relation for an entity set E * The relations for many-one relationships where E is the “many.” Example: Drinkers(name, addr) and Favorite(drinker, beer) combine to make Drinkers1(name, addr, favBeer). Drinkers(name, addr) Drinkers1(name, addr, favBeer) + Drinkers name addr Beers manf Favorite Drinkers1 name addr favBeer Beers manf Favorite(drinker, beer)

Risk with combining relations in many-many relationships

Risk with combining relations in many-many relationships Combining Drinkers with Likes would be a mistake. It leads to redundancy, as: Drinkers name addr Beers manf Likes

Risk with combining relations in many-many relationships Combining Drinkers with Likes would be a mistake. It leads to redundancy, as: Drinkers name addr Beers manf Likes Drinkers2 name addr beer Beers name manf

Risk with combining relations in many-many relationships Combining Drinkers with Likes would be a mistake. It leads to redundancy, as: Drinkers name addr Beers manf Likes Drinkers2 name addr beer Beers name manf Drinkers2 name addr beer Sally 123 Maple Bud Sally 123 Maple Miller

Risk with combining relations in many-many relationships Combining Drinkers with Likes would be a mistake. It leads to redundancy, as: Drinkers name addr Beers manf Likes Drinkers2 name addr beer Beers name manf Drinkers2 name addr beer Sally 123 Maple Bud Sally 123 Maple Miller Redundancy

Handling Weak Entity Sets

Handling Weak Entity Sets Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own attributes.

Handling Weak Entity Sets Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own attributes. A supporting relationship is redundant and yields no relation (unless it has attributes).

Handling Weak Entity Sets Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own attributes. A supporting relationship is redundant and yields no relation (unless it has attributes). Example: Logins Hosts At name billTo location

Handling Weak Entity Sets Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own attributes. A supporting relationship is redundant and yields no relation (unless it has attributes). Example: Logins Hosts At name billTo location Hosts(hostName, location) Logins(loginName, hostName, billTo)

Handling Weak Entity Sets Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own attributes. A supporting relationship is redundant and yields no relation (unless it has attributes). Example: Logins Hosts At name billTo location Hosts(hostName, location) Logins(loginName, hostName, billTo) At(loginName, hostName, hostName2)

Handling Weak Entity Sets Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own attributes. A supporting relationship is redundant and yields no relation (unless it has attributes). Example: Logins Hosts At name billTo location Hosts(hostName, location) Logins(loginName, hostName, billTo) At(loginName, hostName, hostName2) Must be the same

Handling Weak Entity Sets Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own attributes. A supporting relationship is redundant and yields no relation (unless it has attributes). Example: Logins Hosts At name billTo location Hosts(hostName, location) Logins(loginName, hostName, billTo) At(loginName, hostName)

Handling Weak Entity Sets Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own attributes. A supporting relationship is redundant and yields no relation (unless it has attributes). Example: Logins Hosts At name billTo location Hosts(hostName, location) Logins(loginName, hostName, billTo) At(loginName, hostName) it becomes part of Logins

Handling Weak Entity Sets Relation for a weak entity set must include attributes for its complete key (including those belonging to other entity sets), as well as its own attributes. A supporting relationship is redundant and yields no relation (unless it has attributes). Example: Logins Hosts At name billTo location Hosts(hostName, location) Logins(loginName, hostName, billTo)

Handling Subclasses: Three Approaches

Handling Subclasses: Three Approaches Object-oriented: One relation per subset of subclasses, with all relevant attributes.

Handling Subclasses: Three Approaches Object-oriented: One relation per subset of subclasses, with all relevant attributes. Use nulls: One relation, entities have NULL in attributes that don’t belong to them.

Handling Subclasses: Three Approaches Object-oriented: One relation per subset of subclasses, with all relevant attributes. Use nulls: One relation, entities have NULL in attributes that don’t belong to them. E/R style: One relation for each subclass: * Key attribute(s). * Attributes of that subclass.

Handling Subclasses: Three Approaches manf name Beers isa Ales color Object-oriented: One relation per subset of subclasses, with all relevant attributes. Use nulls: One relation, entities have NULL in attributes that don’t belong to them. E/R style: One relation for each subclass: * Key attribute(s). * Attributes of that subclass.

Handling Subclasses: Three Approaches manf name Beers isa Ales color Object-oriented: One relation per subset of subclasses, with all relevant attributes. Use nulls: One relation, entities have NULL in attributes that don’t belong to them. E/R style: One relation for each subclass: * Key attribute(s). * Attributes of that subclass. Object-oriented

Handling Subclasses: Three Approaches manf name Beers isa Ales color Object-oriented: One relation per subset of subclasses, with all relevant attributes. Use nulls: One relation, entities have NULL in attributes that don’t belong to them. E/R style: One relation for each subclass: * Key attribute(s). * Attributes of that subclass. Object-oriented Beers name manf bud Anheuser-Busch Ales name manf color Summerbrew Pete’s dark

Handling Subclasses: Three Approaches manf name Beers isa Ales color Object-oriented: One relation per subset of subclasses, with all relevant attributes. Use nulls: One relation, entities have NULL in attributes that don’t belong to them. E/R style: One relation for each subclass: * Key attribute(s). * Attributes of that subclass. Object-oriented Beers name manf bud Anheuser-Busch Ales name manf color Summerbrew Pete’s dark Good for queries like “find the color of ales made by Pete’s.”

Handling Subclasses: Three Approaches manf name Beers isa Ales color Object-oriented: One relation per subset of subclasses, with all relevant attributes. Use nulls: One relation, entities have NULL in attributes that don’t belong to them. E/R style: One relation for each subclass: * Key attribute(s). * Attributes of that subclass. Use nulls

Handling Subclasses: Three Approaches manf name Beers isa Ales color Object-oriented: One relation per subset of subclasses, with all relevant attributes. Use nulls: One relation, entities have NULL in attributes that don’t belong to them. E/R style: One relation for each subclass: * Key attribute(s). * Attributes of that subclass. Use nulls Beers name manf color Bud Anheuser-Busch NULL Summerbrew Pete’s dark

Handling Subclasses: Three Approaches manf name Beers isa Ales color Object-oriented: One relation per subset of subclasses, with all relevant attributes. Use nulls: One relation, entities have NULL in attributes that don’t belong to them. E/R style: One relation for each subclass: * Key attribute(s). * Attributes of that subclass. Use nulls Beers name manf color Bud Anheuser-Busch NULL Summerbrew Pete’s dark Save space unless there are lots of attributes that are usually NULL

Handling Subclasses: Three Approaches manf name Beers isa Ales color Object-oriented: One relation per subset of subclasses, with all relevant attributes. Use nulls: One relation, entities have NULL in attributes that don’t belong to them. E/R style: One relation for each subclass: * Key attribute(s). * Attributes of that subclass. E/R Style

Handling Subclasses: Three Approaches manf name Beers isa Ales color Object-oriented: One relation per subset of subclasses, with all relevant attributes. Use nulls: One relation, entities have NULL in attributes that don’t belong to them. E/R style: One relation for each subclass: * Key attribute(s). * Attributes of that subclass. E/R Style Beers name manf Bud Anheuser-Busch Summerbrew Pete’s Ales name color Summerbrew dark

Handling Subclasses: Three Approaches manf name Beers isa Ales color Object-oriented: One relation per subset of subclasses, with all relevant attributes. Use nulls: One relation, entities have NULL in attributes that don’t belong to them. E/R style: One relation for each subclass: * Key attribute(s). * Attributes of that subclass. E/R Style Beers name manf Bud Anheuser-Busch Summerbrew Pete’s Ales name color Summerbrew dark Good for queries like “find all beers (including ales) made by Peter’s.”

Outline of Course Representing things by tables E-R model (Ch. 4)
Good table structures Functional Dependencies (Ch.3) Basic operations on relations Relational Algebra (Ch. 2) Storage management (Chs ) SQL languages in DDL/DML (Ch. 6) Query processing (Chs ) More on SQL (Chs. 7-9) Transition processing (Chs )

Outline of Course Representing things by tables E-R model (Ch. 4)
Good table structures functional dependencies (Ch.3） Basic operations on relations Relational Algebra (Ch. 2) Storage management (Chs ) SQL languages in DDL/DML (Ch. 6) Query processing (Chs ) More on SQL (Chs. 7-9) Transition processing (Chs )

Review on Tables (Relations)
name manf Winterbrew Peter’s Bud Lite Anheuser-Busch Beers

attributes (column headers) name manf Winterbrew Peter’s Bud Lite Anheuser-Busch tuples (rows) table/relation name Beers

attributes (column headers) name manf Winterbrew Peter’s Bud Lite Anheuser-Busch tuples (rows) table/relation name Beers Attributes A determine attribute b: two tuples with the same values in A must have the same value in b.

attributes (column headers) name manf Winterbrew Peter’s Bud Lite Anheuser-Busch tuples (rows) table/relation name Beers Attributes A determine attribute b: two tuples with the same values in A must have the same value in b. Superkey: a set of attributes that determines all other attributes.

attributes (column headers) name manf Winterbrew Peter’s Bud Lite Anheuser-Busch tuples (rows) table/relation name Beers Attributes A determine attribute b: two tuples with the same values in A must have the same value in b. Superkey: a set of attributes that determines all other attributes. Key: a minimal superkey.

attributes (column headers) name manf Winterbrew Peter’s Bud Lite Anheuser-Busch tuples (rows) table/relation name Beers Attributes A determine attribute b: two tuples with the same values in A must have the same value in b. Superkey: a set of attributes that determines all other attributes. Key: a minimal superkey. Every relation has a key

What makes a bad table?

Likes(drinker, addr, zip, beer, manf)
What makes a bad table? Example: consider the relation Likes(drinker, addr, zip, beer, manf)

Likes(drinker, addr, zip, beer, manf)
What makes a bad table? Example: consider the relation Likes(drinker, addr, zip, beer, manf) Record the information that the drinker living in addr with zipcode zip likes the beer made by manf.

What makes a bad table? drinker addr zip beer manf Janeway
21 A street, Austin 78702 Bud A. B. Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002

What makes a bad table? Because name determines addr drinker addr zip
beer manf Janeway 21 A street, Austin 78702 Bud A. B. Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 Because name determines addr

What makes a bad table? Because name determines addr Because beer
drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 Because name determines addr Because beer determines manf

What makes a bad table? The redundancy of information will drinker
addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 The redundancy of information will

What makes a bad table? The redundancy of information will
drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 The redundancy of information will Waste space.

drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 The redundancy of information will Waste space. Cause logic inconsistency

drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 The redundancy of information will Waste space. Cause logic inconsistency * update anomaly;

drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. 29 A street, Austin Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 The redundancy of information will Waste space. Cause logic inconsistency * update anomaly;

drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. 29 A street, Austin Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 The redundancy of information will Waste space. Cause logic inconsistency * update anomaly; * deletion anomaly.

drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. 29 A street, Austin Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 The redundancy of information will Waste space. Cause logic inconsistency * update anomaly; * deletion anomaly. Lost the information that Spock lives in 32 B Street, Austin

What makes a bad table? drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. 29 A street, Austin Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 All these come from some non-superkeys that determine some other attributes.

What makes a bad table? drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. 29 A street, Austin Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 All these come from some non-superkeys that determine some other attributes. We should eliminate such functional dependencies.

What makes a bad table? drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. 29 A street, Austin Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 All these come from some non-superkeys that determine some other attributes. We should eliminate such functional dependencies. How? → check every non-superkey,

What makes a bad table? drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. 29 A street, Austin Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 All these come from some non-superkeys that determine some other attributes. We should eliminate such functional dependencies. How? → check every non-superkey, but How?

What makes a bad table? drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. 29 A street, Austin Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 All these come from some non-superkeys that determine some other attributes. We should eliminate such functional dependencies. How? → check every non-superkey, but How? The table itself gives some obvious dependencies

What makes a bad table? drinker addr zip beer manf Janeway 21 A street, Austin 78702 Bud A. B. 29 A street, Austin Bud Lite WichedAle Peter’s Spock 32 B street, Houston 77002 All these come from some non-superkeys that determine some other attributes. We should eliminate such functional dependencies. How? → check every non-superkey, but How? The table itself gives some obvious dependencies But there can be non-obvious ones

Functional Dependencies
Definition. X → A is an assertion about a relation R that whenever two tuples of R agree on all the attributes of X, then they must also agree on the attribute A.

Definition. X → A is an assertion about a relation R that whenever two tuples of R agree on all the attributes of X, then they must also agree on the attribute A. Say “X (functionally) determines A (in R).”

Definition. X → A is an assertion about a relation R that whenever two tuples of R agree on all the attributes of X, then they must also agree on the attribute A. Say “X (functionally) determines A (in R).” Convention: …, X, Y, Z represent sets of attributes; A, B, C, … represent single attributes.

Definition. X → A is an assertion about a relation R that whenever two tuples of R agree on all the attributes of X, then they must also agree on the attribute A. Say “X (functionally) determines A (in R).” Convention: …, X, Y, Z represent sets of attributes; A, B, C, … represent single attributes. Convention: write ABC instead of {A,B,C}.

Definition. X → A is an assertion about a relation R that whenever two tuples of R agree on all the attributes of X, then they must also agree on the attribute A. Say “X (functionally) determines A (in R).” Convention: …, X, Y, Z represent sets of attributes; A, B, C, … represent single attributes. Convention: write ABC instead of {A,B,C}. Our main goal is to find non-superkeys X that determine other attributes

No need for FD’s with more than one attribute on right.

No need for FD’s with more than one attribute on right. * But sometimes convenient to combine FD’s as a shorthand.

No need for FD’s with more than one attribute on right. * But sometimes convenient to combine FD’s as a shorthand. * Example: drinker → addr and drinker → zip are the same as drinker → addr zip

No need for FD’s with more than one attribute on right. * But sometimes convenient to combine FD’s as a shorthand. * Example: drinker → addr and drinker → zip are the same as drinker → addr zip > 1 attribute on left may be essential.

No need for FD’s with more than one attribute on right. * But sometimes convenient to combine FD’s as a shorthand. * Example: drinker → addr and drinker → zip are the same as drinker → addr zip > 1 attribute on left may be essential. * Example: bar beer → price but NOT bar → price or beer → price

Thus, a superkey is a set X of attributes such that X → A for all attributes A in R. A key is a superkey in which no subset makes a superkey.

Thus, a superkey is a set X of attributes such that X → A for all attributes A in R. A key is a superkey in which no subset makes a superkey. Example. Likes(drinker, addr, zip, beer, manf)

Thus, a superkey is a set X of attributes such that X → A for all attributes A in R. A key is a superkey in which no subset makes a superkey. Example. Likes(drinker, addr, zip, beer, manf) * {drinker, zip, beer, manf} is a superkey.

Thus, a superkey is a set X of attributes such that X → A for all attributes A in R. A key is a superkey in which no subset makes a superkey. Example. Likes(drinker, addr, zip, beer, manf) * {drinker, zip, beer, manf} is a superkey. * there are many other superkeys.

Thus, a superkey is a set X of attributes such that X → A for all attributes A in R. A key is a superkey in which no subset makes a superkey. Example. Likes(drinker, addr, zip, beer, manf) * {drinker, zip, beer, manf} is a superkey. * there are many other superkeys. * {drinker, beer} is a key (the only key)

E/R and Relational Keys
Keys in E/R concern entities. Keys in relations concern tuples.

Keys in E/R concern entities. Keys in relations concern tuples. Usually, one tuple corresponds to one entity, so the ideas are the same.

Keys in E/R concern entities. Keys in relations concern tuples. Usually, one tuple corresponds to one entity, so the ideas are the same. But --- in poor relational designs, one entity can become several tuples, so E/R keys and Relational keys are different.

Where Do Keys Come From?

Where Do Keys Come From? Just assert a key K.
* The only FD’s are K →A for all attributes A.

* The only FD’s are K →A for all attributes A. Assert FD’s and deduce the keys by systematic exploration.

* The only FD’s are K →A for all attributes A. Assert FD’s and deduce the keys by systematic exploration. * E/R model gives us FD’s from entity-set keys and from many-one relationships.

* The only FD’s are K →A for all attributes A. Assert FD’s and deduce the keys by systematic exploration. * E/R model gives us FD’s from entity-set keys and from many-one relationships. FD’s from “physics”.

* The only FD’s are K →A for all attributes A. Assert FD’s and deduce the keys by systematic exploration. * E/R model gives us FD’s from entity-set keys and from many-one relationships. FD’s from “physics”. * Example: “no two courses can meet in the same room at the same time” tells us: hour room → course.

CPSC-310 Database Systems

Similar presentations

Presentation on theme: "CPSC-310 Database Systems"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

CPSC-310 Database Systems

Similar presentations

Presentation on theme: "CPSC-310 Database Systems"— Presentation transcript:

Similar presentations

About project

Feedback