Transcript Relational Data Model - Department Of Computer Science

Database Management Systems
Chapter 3
The Relational Data Model (I)
Instructor: Li Ma
Department of Computer Science
Texas Southern University, Houston
September, 2006
The Relational Data Model
Tables
Schemas
Conversion from E/R to Relations
A Relation is a Table
Attributes
(column
headers)
Tuples
(rows)
name
manf
Winterbrew
Pete’s
Bud Lite
Anheuser-Busch
Beers
Jeffrey Ullman
3
Schemas
Relation schema = relation name and
attribute list.
 Optionally: types of attributes.
 Example: Beers(name, manf) or
Beers(name: string, manf: string)
Relation instance = current set of rows.
Database = collection of relations.
Database schema = set of all relation
schemas in the database.
Jeffrey Ullman
4
Relational Data Model
Set theoretic
Relation as table
Rows = tuples
Domain — set of values
Columns = components
like a data type
Names of columns = attributes
Cartesian product (or product)
Set of attribute names = schema
D1 D2 ...  Dn
REL (A1,A2,...,An)
n-tuples (V1,V2,...,Vn)
s.t., V1 D1, V2 D2,...,Vn Dn
A1 A2 A3 ... An
C
a
r
d
i
n
a
l
i
t
y
a1 a2 a3
an
b1 b2 a3
cn
a1 c3 b3
.
.
.
bn
x1 v2 d3
wn
Arity
Attributes
Tuple
Component
Relation-subset of cartesian product
of one or more domains
FINITE only; empty set allowed
Tuples = members of a relation inst.
Arity = number of domains
Components = values in a tuple
Domains — corresp. with attributes
Cardinality = number of tuples
Jeffrey Ullman
5
Relation: Example
Name
address
tel #
5
3
7
Cardinality of domain
Attribute
Domains
Domain of
Relation
N
A
T
N1 A1 T1
Arity
3
Cardinality
<=5x3x7
of relation
N1 A1 T2
N1 A1 T3
N
A
T
N1
A1
T1
N2
A2
T2
N1 A1 T7
N3
A3
T3
N1 A2 T1
N4
T4
N1 A3 T1
N5
T5
N2 A1 T1
Component
.
……
.
Tuple µ
T6
T7
Domain
Jeffrey Ullman
6
Relation Instance
Name
Address
Telephone
Bob
123 Main St
555-1234
Bob
128 Main St
555-1235
Pat
123 Main St
555-1235
Harry
456 Main St
555-2221
Sally
456 Main St
555-2221
Sally
456 Main St
555-2223
Pat
12 State St
555-1235
Jeffrey Ullman
7
About Relational Model
Order of tuples not important
Order of attributes not important (in theory)
Collection of relation schemas (intension)
Relational database schema
Corresponding relation instances (extension)
Relational database
intension vs. extension
schema vs. data
metadata
includes schema
Jeffrey Ullman
8
Why Relations?
Very simple model.
Often a good match for the way we
think about our data.
Abstract model that underlies SQL, the
most important language in DBMS’s
today.
 But SQL uses “bags” while the abstract
relational model is set-oriented.
Jeffrey Ullman
9
From E/R Diagrams to Relations
Entity set -> relation.
 Attributes -> attributes.
Relationships -> relations whose
attributes are only:
 The keys of the connected entity sets.
 Attributes of the relationship itself.
Jeffrey Ullman
10
Keys in Relations
An attribute or set of attributes K is a key
for a relation R if we expect that in no
instance of R will two different tuples
agree on all the attributes of K.
Indicate a key by underlining the key
attributes.
Example: If name is a key for Beers:
Beers(name, manf)
Jeffrey Ullman
11
Entity Set -> Relation
name
manf
Beers
Relation: Beers(name, manf)
Jeffrey Ullman
12
Relationship -> Relation
name
husband
addr
Drinkers
1
name
Likes
manf
Beers
2
Buddies
Favorite
wife
Married
Likes(drinker, beer)
Favorite(drinker, beer)
Buddies(name1, name2)
Married(husband, wife)
Jeffrey Ullman
13
Combining Relations
 OK to combine into one relation:
1. The relation for an entity-set E
2. The relations for many-one relationships
of which E is the “many.”
 Example: Drinkers(name, addr) and
Favorite(drinker, beer) combine to
make Drinker1(name, addr, favBeer).
Jeffrey Ullman
14
Risk with Many-Many Relationships
Combining Drinkers with Likes would be
a mistake. It leads to redundancy, as:
name
addr
beer
Sally 123 Maple Bud
Sally 123 Maple Miller
Redundancy
Jeffrey Ullman
15
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, nonkey
attributes.
A supporting relationship is redundant
and yields no relation (unless it has
attributes).
Jeffrey Ullman
16
Example
name
billTo
Logins
name
At
Hosts
location
Hosts(hostName, location)
Logins(loginName, hostName, billTo)
At(loginName, hostName, hostName2)
At becomes part of
Logins
Must be the same
Jeffrey Ullman
17
Subclasses: Three Approaches
1. Object-oriented : One relation per subset of
subclasses, with all relevant attributes.
2. E/R style : One relation for each subclass:
 Key attribute(s).
 Attributes of that subclass.
3. Use nulls : One relation; entities have NULL
in attributes that don’t belong to them.
Jeffrey Ullman
18
Example
name
Beers
manf
isa
color
Ales
Jeffrey Ullman
19
Object-Oriented
name
manf
Bud Anheuser-Busch
Beers
name
manf
Summerbrew Pete’s
Ales
color
dark
Good for queries like “find the
color of ales made by Pete’s.”
Jeffrey Ullman
20
E/R Style
name
manf
Bud
Anheuser-Busch
Summerbrew Pete’s
Beers
name
Summerbrew
color
dark
Ales
Good for queries like
“find all beers (including
ales) made by Pete’s.”
Jeffrey Ullman
21
Using Nulls
name
Bud
Summerbrew
manf
Anheuser-Busch
Pete’s
Beers
color
NULL
dark
Saves space unless there are lots
of attributes that are usually NULL.
Jeffrey Ullman
22