Lecture 2 - Relational Model

Relational Model
• In the relational data model
– a database is a set of tables (with additional constraints,
programs and interfaces)
– a schema is the description of tables in a database
– a relation or a table is a “set” of tuples
– a tuple or a record is a mapping from a set of attributes to their
values
– an attribute is a slot for recording data, it has a name and a
domain of applicable values
– the schema of a table contains the table’s name and the
attributes and the domain of the attributes

Fall 2001 Database Systems 1

Example Database - Auction

• OWNERS - people who sell items
– Oid unique identifier given to them
– Name their name
– Email their e-mail address

• ITEMS - the items sold by “owners”

– Iid unique identifier of an item being sold
– Oid the owner of the item
– Name description of the item
– Location location of the item

• BUYERS - registered buyers allowed to bid on items

– Buyid buyer identifier
– Name buyer’s name
– Email buyer’s e-mail address

Fall 2001 Database Systems 2

1
 Lecture 2 - Relational Model

Example Database - Auction

• BIDS - people place bids on a specific item of a
specific owner
– Bid unique identifier of a bid
– Date the date it was put online
– Iid which item
– Oid who owns the item
– Buyid who placed the bid
– Amount how much is the buyer bidding

• Additional logic:
– BIDS and ITEMS contain all the “unsold” items.
As soon as an item is sold, it is deleted from
bids and items. The loosing bidders are notified
that they lost the item.
Fall 2001 Database Systems 3


 
    
 78:9;<= 7'>6?@ A BCEDGF ;DGC@ H
    Smith@aol.com IKJ L:M-N)O Gray@microsoft,com

! "$#%'&)( Johns@geocities.com PQ R'ST%U'VXW YRobert432@aol.com

* +',-#/.& Brown@netmail.com P'Z [KSE\]^Y Johns@somewhere.co

10 23,-465 P%_ [`%Y)S]

m
Gray@microsoft.com Jj@yahoo.com

P'a b3ced)U Duke@jazz.com

³'´'µ3¶ ³K· ¸ µ:¹Eº » ´· ¸ ¼· ¸ ³'½6¾´E¸ ¿ÀGÁ%½%Â/º fegihjk fl m  n l m Go pqir set6u/pev/l tew
ÃKÄ ÅKÆ Ç'È%É'Ê ËÆ ÌÆ ÃKÍ ÆÎÊÊ x'y  z y 1{ |-}e~ e€) †E‡6ˆ)}^‡|
ÃKÄ ÅKÍ Ç'È%É'Ê ËeÏ ÌÉ ÃÐ É'ÊÊ'ÊÊ ‚/ƒ6„…
ÃKÄ ÅÉ Ç'È%ÉKÆ ËÆ ÌÆ ÃKÍ Æ^ÍÊ x'‰ z‰ Š$‹EƒeŒ6eˆ6…/eƒeX ”i‡e€)ˆ)}-‡|
ÃKÄ ÅÏ Ñ'ÈEÆ ËEÒ ÌÉ ÃÐ ÍÏKÊ'ÊÊ Ž ‡/„…E %} ‘“’
ÃKÄ ÅÐ Ñ'ÈEÆ ËÆ ÌÆ ÃKÍ Æ^ÍÆ x• z‰ Š$‹EƒeŒ6eˆ6…/eƒeX –Ge—
ÃKÄ ÅÒ Ñ'ÈEÍ ËeÏ ÌÉ ÃÏ ÉÐ'Ê'ÊÊ Ž ‡/„…E %} ‘“’ ˜K‡e Œ
ÃKÄ Å'Ó Ñ'ÈEÍ ËÍ ÌÍ ÃKÆ ÍÐ'Ê ™%š ›œ žeŸ- )¡%¢-¢ ¡ £$¤E¥ ¥ ¤/¦
ÃKÄ ÅÇ Ñ'È%É ËÍ ÌÍ ÃÉ ÍÊÊ ™§ ›Gš ¨¤e©e©ª%« ¯ ¡%¤6¢^¢e¥ ¡
žE¥ ¥ ¡E¬)¢6­ ž®
™E° ›± žeŸ- )¡%¢-¢ ¡ ²Ež6¦)¢^ž®
Fall 2001 Database Systems 4

2
 Lecture 2 - Relational Model

Attributes and Domains

• Let D1 = the letter “O” followed by the set of all
integers
D2 = the set of all strings up to 30 characters
that contain only letters A-Z,a-z
D3 = the set of all strings that contain a single
@ symbol, and a combination of
Alphanumeric characters and “.”.
Then, owners relation has schema
Owners(OID:D1, Name:D2, Email:D3)

Fall 2001 Database Systems 5

Attributes - Domains
• All tuples in Owners come from
– D1 × D2 × D3
– An example tuple: <OID:O1, Name: ’Smith’,
Email: ‘smith@aol.com’>
– For any tuple: <OID:v1, Name: v2, Email: v3>
we have the property that v1 ∈ D1, v2 ∈ D2, v3 ∈ D3
• We usually abuse notation and assume an ordering
for the attribute/domain pairs, and write the relation
schema as:
Owners(OID, Name, Email)
and a tuple as:
<O1,’Smith’,’smith@aol.com> ∈ Owners

Fall 2001 Database Systems 6

3
 Lecture 2 - Relational Model

More on domains
• A domain is a type in the programming language sense
• Domain values is a set of acceptable values for a
variable of a given type.
– Zipcode: zipcodeDomain = {11111, … ,99999},
– Grants: availableGrants = {50,000, … ,1,000,000}
– Simple/Composite domains
• Address = Street name+street number+city+province+ postal code
• Domain compatibility
– Binary operations (e.g., comparison to one another, addition, etc)
can be performed on them.
• Full support for domains is not provided in many current
relational DBMSs

Fall 2001 Database Systems 7

Relation Instances
• A relation/table instance is a set of tuples with a
specific schema (attribute/domain pairs)
List form:
OWNERS(OID,Name,Email) = { <O1, Smith, smith@aol.com>,
<O2, Johns, johns@geocities.com>, <O3, Brown,
Brown@netmail.com>, <O4, Gray, Gray@microsoft.com> }

Tabular form: ÔÕÖ×KØÙ ÔÚ Û ÖÜEÝ1Þ ×ÝGÜÚ ß

àá âäãå æ)ç Smith@aol.com

àè é$êeç'ë6ì Johns@geocities.com

àí îï-êeðië Brown@netmail.com

à1ñ ò3ï-ó)ô Gray@microsoft.com

Fall 2001 Database Systems 8

4
 Lecture 2 - Relational Model

Relational Model
Based on finite set theory:
• First Normal Form Rule: all attributes take simple
values - no set values are allowed.
• Rows are accessed only by their content. The order of
tuples does not have any meaning.
• The order of columns does not have any specific
meaning either.
• No two tuples can have the same values for all the
attributes, i.e. relations are sets.
• Commercial systems allow duplicates (so bag
semantics)
Fall 2001 Database Systems 9

Keys
• A superkey is a set of attributes that help uniquely
identify a specific tuple
– if no two owners may have the same Oid, then Oid
is a superkey
– if no two owners may have the same email
address, then Email is a superkey
• How about:
– Oid + Name (together) for Owners?
– Oid + Name (together) for ITEMS?
– Iid + Oid (together) for ITEMS?

Fall 2001 Database Systems 10

5
 Lecture 2 - Relational Model

Keys
• Given relation T, we use t[A1,…,Ak] to denote tuples with only
attributes A1,…,Ak
– for example, if t = <O1, Smith, smith@aol.com> then
t[oid,name] = <O1, Smith>

• Given a relation T with attributes {A1,…,Ak}, a key is a set of

attributes {B1,…,Bm} ⊆ {A1,…,Ak} such that
– if u and v are distinct tuples in relation T, then u[B1,…,Bm] and
v[B1,…,Bm] are necessarily different from each other by user
design!
– no proper subset of {B1,…,Bm} has this property

• Every table must have a unique primary key

– Primary key is a key designated by the user and managed by

the system
Fall 2001 Database Systems 11

Null values
• Attributes may be allowed to have null values because
– a value does not exist for a tuple
– a value exists, but it is not known
– it is not known whether a value exists or not

• Integrity rule: No column in a primary key can have null

values

Fall 2001 Database Systems 12